On 20/4/21 4:12 am, Sebastian Huber wrote: > On 19/04/2021 18:48, Gedare Bloom wrote: > >>>> A random pick of a file and a brief scan ... >>>> >>>> https://git.rtems.org/rtems-central/tree/rtemsspec/interface.py#n313 >>> There is no issue in this line.
I disagree. At a technical level there is an issue. Python provides os.linesep to handle this specific case. Any place you force the ending the has to be considered code brittle. Maybe the code will not show any issue but what it creates may. >> I believe some can configure their git to inject \n\r on clone/pull >> and fixes it up on commit. I have to do this for example to use >> Windows source files in some projects where the IDE is only available >> there. > > This code generates C source files for RTEMS. These files should have Unix > line > endings. A more specific and maybe better version of this sentence is ... "This code generates C source files for RTEMS on the host the generator is run on. The files have host's end of line encoding." > There are probably Git users on Windows which enable the LF to CRLF > conversion. > There are probably also Git users on Windows which don't enable this feature. This should be covered by the format we hold for the files in the repo and what the user has or uses is for them to manage. If a tool such as a git defaults to the host standard and our tools also use that same default then things should work. My experience over the last decade of the RSB has taught me if it is wrong it will show up. A guide needs to cover these issues and we need to review so our code meets those guide lines. Chris _______________________________________________ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel