-
Notifications
You must be signed in to change notification settings - Fork 51
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Added API allowing user to choose settings at runtime - replacement of PR#49 #51
Changes from all commits
File filter
Filter by extension
Conversations
Jump to
Diff view
Diff view
There are no files selected for viewing
Original file line number | Diff line number | Diff line change |
---|---|---|
|
@@ -89,9 +89,9 @@ | |
|
||
/* Note time_t must be used here otherwise will have bugs when 2032 (uint32_t second clock rolls over) */ | ||
#if ( ffconfigTIME_SUPPORT == 1 ) | ||
time_t st_atime; | ||
time_t st_mtime; | ||
time_t st_ctime; | ||
time_t ff_atime; | ||
time_t ff_mtime; | ||
time_t ff_ctime; | ||
Comment on lines
+92
to
+94
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. Is this a backward compatible change? An in what happens to users using these fields? Or are these internal? There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. No it is not backwards compatible - This is to fix #50 . What is allowed and not allowed in terms of breaking compatibility for Lab projects? There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. @phelter asked:
There is not an official guideline about "breaking compatibility". I'd like to break as little as possible, and avoid complex or tricky constructions like the use of I just compiled a big Xilinx project, which contains an FTP-server and a compression module, all with I must say that the code rarely refers to the one of the 3 fields ( Another way to void compilation errors would be :
but that might cause problems in applications that also use stdio.h Note that the compiler error is easy to understand:
Can you add some comments about the compatibility break? There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. If compatibility with many different flavors of environments what I'd suggest is:
@htibosch - are you referring to adding comments in the code about compatibility issues? If so I'd suggest the code is not the place for that, but release notes between versions is a better place to provide that type of information - i.e. provide search/replace information on compatibility breaks. Happy to provide a sed script if you like. Something like:
|
||
#endif /* ffconfigTIME_SUPPORT */ | ||
} FF_Stat_t; | ||
|
||
|
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Same here. Would this break existing users code?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Can you please have a look at my earlier response?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This would only break existing user code if they are accessing the values inside the pxStatBuffer in their code in some way associated with
st_[a|m|c]time
. It can be mitigated by providing users a description of the breaking change in thisLab-Project
based repo.The other option is to possibly investigate replacing the entire struct for Linux based examples with the linux
stat
structure instead of using home-grown version, and ensuring compatibility between the FF_Stat and linuxstat
is maintained - see #50 (comment).