From: SourceForge.net <no...@so...> - 2012-02-22 09:00:06
|
Bugs item #3490776, was opened at 2012-02-22 01:00 Message generated for change (Tracker Item Submitted) made by spth You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=100599&aid=3490776&group_id=599 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: None Group: None Status: Open Resolution: None Priority: 5 Private: No Submitted By: Philipp Klaus Krause (spth) Assigned to: Philipp Klaus Krause (spth) Summary: Feature macros Initial Comment: sdcc does not provide complex types, variable-length arrays, multithreading and atomics. While this is allowed by the C11 standard (and with the exception of variable-length arrays by the C99 standard), implementations that do not provide these features have to define the __STDC_NO_COMPLEX__, __STDC_NO_VLA_, __STDC_NO_THREADS__ and __STDC_NO_ATOMICS__ macros. Philipp ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=100599&aid=3490776&group_id=599 |
From: SourceForge.net <no...@so...> - 2012-02-22 15:58:22
|
Bugs item #3490776, was opened at 2012-02-22 01:00 Message generated for change (Comment added) made by spth You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=100599&aid=3490776&group_id=599 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: None Group: None >Status: Closed >Resolution: Fixed Priority: 5 Private: No Submitted By: Philipp Klaus Krause (spth) Assigned to: Philipp Klaus Krause (spth) Summary: Feature macros Initial Comment: sdcc does not provide complex types, variable-length arrays, multithreading and atomics. While this is allowed by the C11 standard (and with the exception of variable-length arrays by the C99 standard), implementations that do not provide these features have to define the __STDC_NO_COMPLEX__, __STDC_NO_VLA_, __STDC_NO_THREADS__ and __STDC_NO_ATOMICS__ macros. Philipp ---------------------------------------------------------------------- >Comment By: Philipp Klaus Krause (spth) Date: 2012-02-22 07:58 Message: Fixed in revision #7324. Philipp ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=100599&aid=3490776&group_id=599 |
From: SourceForge.net <no...@so...> - 2012-02-26 08:34:01
|
Bugs item #3490776, was opened at 2012-02-22 01:00 Message generated for change (Comment added) made by maartenbrock You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=100599&aid=3490776&group_id=599 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. >Category: C Preprocessor >Group: fixed >Status: Open >Resolution: Remind Priority: 5 Private: No Submitted By: Philipp Klaus Krause (spth) Assigned to: Philipp Klaus Krause (spth) Summary: Feature macros Initial Comment: sdcc does not provide complex types, variable-length arrays, multithreading and atomics. While this is allowed by the C11 standard (and with the exception of variable-length arrays by the C99 standard), implementations that do not provide these features have to define the __STDC_NO_COMPLEX__, __STDC_NO_VLA_, __STDC_NO_THREADS__ and __STDC_NO_ATOMICS__ macros. Philipp ---------------------------------------------------------------------- >Comment By: Maarten Brock (maartenbrock) Date: 2012-02-26 00:34 Message: Philipp, With your fix for this item you've broken code for everyone depending on the documented predefined macros. And unless I missed it the compiler gives no warning to the user about it. I think we need to warn the user when we encounter something (macro-like?) that starts with 'SDCC'. Furthermore you forgot to update compiler.h which btw in my opinion needs to stay compiler version independent. Thus the check for 'SDCC' needs to stay but can be OR-ed with '__SDCC'. I have therefor reopened this item. ---------------------------------------------------------------------- Comment By: Philipp Klaus Krause (spth) Date: 2012-02-22 07:58 Message: Fixed in revision #7324. Philipp ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=100599&aid=3490776&group_id=599 |
From: SourceForge.net <no...@so...> - 2012-02-26 14:59:52
|
Bugs item #3490776, was opened at 2012-02-22 01:00 Message generated for change (Comment added) made by spth You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=100599&aid=3490776&group_id=599 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: C Preprocessor Group: fixed Status: Open Resolution: Remind Priority: 5 Private: No Submitted By: Philipp Klaus Krause (spth) Assigned to: Philipp Klaus Krause (spth) Summary: Feature macros Initial Comment: sdcc does not provide complex types, variable-length arrays, multithreading and atomics. While this is allowed by the C11 standard (and with the exception of variable-length arrays by the C99 standard), implementations that do not provide these features have to define the __STDC_NO_COMPLEX__, __STDC_NO_VLA_, __STDC_NO_THREADS__ and __STDC_NO_ATOMICS__ macros. Philipp ---------------------------------------------------------------------- >Comment By: Philipp Klaus Krause (spth) Date: 2012-02-26 06:59 Message: Hmm, where should we warn? In the preprocessor? Another option would be to bring back the old macro names when using --std-sdcc89 or --std-sdcc99 and marking them as deprecated in the documentation (which I should update for this change anyway). Philipp ---------------------------------------------------------------------- Comment By: Maarten Brock (maartenbrock) Date: 2012-02-26 00:34 Message: Philipp, With your fix for this item you've broken code for everyone depending on the documented predefined macros. And unless I missed it the compiler gives no warning to the user about it. I think we need to warn the user when we encounter something (macro-like?) that starts with 'SDCC'. Furthermore you forgot to update compiler.h which btw in my opinion needs to stay compiler version independent. Thus the check for 'SDCC' needs to stay but can be OR-ed with '__SDCC'. I have therefor reopened this item. ---------------------------------------------------------------------- Comment By: Philipp Klaus Krause (spth) Date: 2012-02-22 07:58 Message: Fixed in revision #7324. Philipp ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=100599&aid=3490776&group_id=599 |
From: SourceForge.net <no...@so...> - 2012-02-27 19:38:33
|
Bugs item #3490776, was opened at 2012-02-22 01:00 Message generated for change (Comment added) made by borutr You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=100599&aid=3490776&group_id=599 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: C Preprocessor Group: fixed Status: Open Resolution: Remind Priority: 5 Private: No Submitted By: Philipp Klaus Krause (spth) Assigned to: Philipp Klaus Krause (spth) Summary: Feature macros Initial Comment: sdcc does not provide complex types, variable-length arrays, multithreading and atomics. While this is allowed by the C11 standard (and with the exception of variable-length arrays by the C99 standard), implementations that do not provide these features have to define the __STDC_NO_COMPLEX__, __STDC_NO_VLA_, __STDC_NO_THREADS__ and __STDC_NO_ATOMICS__ macros. Philipp ---------------------------------------------------------------------- >Comment By: Borut Ražem (borutr) Date: 2012-02-27 11:38 Message: I share Maarten's concerns about the change of predefined macros: it breaks the backward compatibility without giving the transition period to sdcc users. I propose to retain old SDCC_* macros and add new __SDCC_* alternative in the similar way we did it for non-double-underscored keywords. In the sdccman.lyx under chapter "1.4 Compatibility with previous versions" it should be stated that SDCC_* macros are deprecated in sdcc vesrion 3.2.0 and will be obsoleted (removed) in in one of next sdcc releases. Users shoud replace SDCC_* nacros with __SDCC_* macros in their code. I don't see how the user could be warned if he is using deprecated SDCC_* macros, but it wold be a nice feature... P.S.: non-double-underscored keywords are now obsoleted (removed), so the statement in chapter "1.4 Compatibility with previous versions": "special sdcc keywords which are not preceded by a double underscore are deprecated in version 3.0.0 and higher. See section ANSI-Compliance." should be replaced with "special sdcc keywords which are not preceded by a double underscore are obsoleted (removed) in version 3.2.0 and higher. See section ANSI-Compliance." Borut ---------------------------------------------------------------------- Comment By: Philipp Klaus Krause (spth) Date: 2012-02-26 06:59 Message: Hmm, where should we warn? In the preprocessor? Another option would be to bring back the old macro names when using --std-sdcc89 or --std-sdcc99 and marking them as deprecated in the documentation (which I should update for this change anyway). Philipp ---------------------------------------------------------------------- Comment By: Maarten Brock (maartenbrock) Date: 2012-02-26 00:34 Message: Philipp, With your fix for this item you've broken code for everyone depending on the documented predefined macros. And unless I missed it the compiler gives no warning to the user about it. I think we need to warn the user when we encounter something (macro-like?) that starts with 'SDCC'. Furthermore you forgot to update compiler.h which btw in my opinion needs to stay compiler version independent. Thus the check for 'SDCC' needs to stay but can be OR-ed with '__SDCC'. I have therefor reopened this item. ---------------------------------------------------------------------- Comment By: Philipp Klaus Krause (spth) Date: 2012-02-22 07:58 Message: Fixed in revision #7324. Philipp ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=100599&aid=3490776&group_id=599 |
From: SourceForge.net <no...@so...> - 2012-02-28 18:13:38
|
Bugs item #3490776, was opened at 2012-02-22 01:00 Message generated for change (Comment added) made by spth You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=100599&aid=3490776&group_id=599 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: C Preprocessor Group: fixed Status: Open Resolution: Remind Priority: 5 Private: No Submitted By: Philipp Klaus Krause (spth) Assigned to: Philipp Klaus Krause (spth) Summary: Feature macros Initial Comment: sdcc does not provide complex types, variable-length arrays, multithreading and atomics. While this is allowed by the C11 standard (and with the exception of variable-length arrays by the C99 standard), implementations that do not provide these features have to define the __STDC_NO_COMPLEX__, __STDC_NO_VLA_, __STDC_NO_THREADS__ and __STDC_NO_ATOMICS__ macros. Philipp ---------------------------------------------------------------------- >Comment By: Philipp Klaus Krause (spth) Date: 2012-02-28 10:13 Message: I expect users of --std-c99 and --std-c89 to value standard compliance higher than backwards-compability. I would like to bring back the old macros for --std-sdcc89 (the current default) and --std-c99. Philipp P.S.: There are some port-specific macros that should be addressed, too. ---------------------------------------------------------------------- Comment By: Borut Ražem (borutr) Date: 2012-02-27 11:38 Message: I share Maarten's concerns about the change of predefined macros: it breaks the backward compatibility without giving the transition period to sdcc users. I propose to retain old SDCC_* macros and add new __SDCC_* alternative in the similar way we did it for non-double-underscored keywords. In the sdccman.lyx under chapter "1.4 Compatibility with previous versions" it should be stated that SDCC_* macros are deprecated in sdcc vesrion 3.2.0 and will be obsoleted (removed) in in one of next sdcc releases. Users shoud replace SDCC_* nacros with __SDCC_* macros in their code. I don't see how the user could be warned if he is using deprecated SDCC_* macros, but it wold be a nice feature... P.S.: non-double-underscored keywords are now obsoleted (removed), so the statement in chapter "1.4 Compatibility with previous versions": "special sdcc keywords which are not preceded by a double underscore are deprecated in version 3.0.0 and higher. See section ANSI-Compliance." should be replaced with "special sdcc keywords which are not preceded by a double underscore are obsoleted (removed) in version 3.2.0 and higher. See section ANSI-Compliance." Borut ---------------------------------------------------------------------- Comment By: Philipp Klaus Krause (spth) Date: 2012-02-26 06:59 Message: Hmm, where should we warn? In the preprocessor? Another option would be to bring back the old macro names when using --std-sdcc89 or --std-sdcc99 and marking them as deprecated in the documentation (which I should update for this change anyway). Philipp ---------------------------------------------------------------------- Comment By: Maarten Brock (maartenbrock) Date: 2012-02-26 00:34 Message: Philipp, With your fix for this item you've broken code for everyone depending on the documented predefined macros. And unless I missed it the compiler gives no warning to the user about it. I think we need to warn the user when we encounter something (macro-like?) that starts with 'SDCC'. Furthermore you forgot to update compiler.h which btw in my opinion needs to stay compiler version independent. Thus the check for 'SDCC' needs to stay but can be OR-ed with '__SDCC'. I have therefor reopened this item. ---------------------------------------------------------------------- Comment By: Philipp Klaus Krause (spth) Date: 2012-02-22 07:58 Message: Fixed in revision #7324. Philipp ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=100599&aid=3490776&group_id=599 |
From: SourceForge.net <no...@so...> - 2012-02-29 16:52:34
|
Bugs item #3490776, was opened at 2012-02-22 01:00 Message generated for change (Comment added) made by borutr You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=100599&aid=3490776&group_id=599 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: C Preprocessor Group: fixed Status: Open Resolution: Remind Priority: 5 Private: No Submitted By: Philipp Klaus Krause (spth) Assigned to: Philipp Klaus Krause (spth) Summary: Feature macros Initial Comment: sdcc does not provide complex types, variable-length arrays, multithreading and atomics. While this is allowed by the C11 standard (and with the exception of variable-length arrays by the C99 standard), implementations that do not provide these features have to define the __STDC_NO_COMPLEX__, __STDC_NO_VLA_, __STDC_NO_THREADS__ and __STDC_NO_ATOMICS__ macros. Philipp ---------------------------------------------------------------------- >Comment By: Borut Ražem (borutr) Date: 2012-02-29 08:52 Message: I would keep the sdcc behavior dependency on --std-xxx as low as possible, so I prefer to keep both versions of predefined macros regardless of --std-xxx setting. Just for example you can see the mess with gcc predefined macros by running cpp -dM < /dev.null: majority of macros is double uderlined, some are single underlined, some has both duble underlined and non uderlined versions, for example unix, __unix, __unix__ and linux, __linux, __linux__, ... But OTOH, your proposal is also not so bad idea. I would like to hear the opinion of other sdcc developers and specially sdcc users. Maybe we should open this discussion on sdcc-user mailing list. Borut ---------------------------------------------------------------------- Comment By: Philipp Klaus Krause (spth) Date: 2012-02-28 10:13 Message: I expect users of --std-c99 and --std-c89 to value standard compliance higher than backwards-compability. I would like to bring back the old macros for --std-sdcc89 (the current default) and --std-c99. Philipp P.S.: There are some port-specific macros that should be addressed, too. ---------------------------------------------------------------------- Comment By: Borut Ražem (borutr) Date: 2012-02-27 11:38 Message: I share Maarten's concerns about the change of predefined macros: it breaks the backward compatibility without giving the transition period to sdcc users. I propose to retain old SDCC_* macros and add new __SDCC_* alternative in the similar way we did it for non-double-underscored keywords. In the sdccman.lyx under chapter "1.4 Compatibility with previous versions" it should be stated that SDCC_* macros are deprecated in sdcc vesrion 3.2.0 and will be obsoleted (removed) in in one of next sdcc releases. Users shoud replace SDCC_* nacros with __SDCC_* macros in their code. I don't see how the user could be warned if he is using deprecated SDCC_* macros, but it wold be a nice feature... P.S.: non-double-underscored keywords are now obsoleted (removed), so the statement in chapter "1.4 Compatibility with previous versions": "special sdcc keywords which are not preceded by a double underscore are deprecated in version 3.0.0 and higher. See section ANSI-Compliance." should be replaced with "special sdcc keywords which are not preceded by a double underscore are obsoleted (removed) in version 3.2.0 and higher. See section ANSI-Compliance." Borut ---------------------------------------------------------------------- Comment By: Philipp Klaus Krause (spth) Date: 2012-02-26 06:59 Message: Hmm, where should we warn? In the preprocessor? Another option would be to bring back the old macro names when using --std-sdcc89 or --std-sdcc99 and marking them as deprecated in the documentation (which I should update for this change anyway). Philipp ---------------------------------------------------------------------- Comment By: Maarten Brock (maartenbrock) Date: 2012-02-26 00:34 Message: Philipp, With your fix for this item you've broken code for everyone depending on the documented predefined macros. And unless I missed it the compiler gives no warning to the user about it. I think we need to warn the user when we encounter something (macro-like?) that starts with 'SDCC'. Furthermore you forgot to update compiler.h which btw in my opinion needs to stay compiler version independent. Thus the check for 'SDCC' needs to stay but can be OR-ed with '__SDCC'. I have therefor reopened this item. ---------------------------------------------------------------------- Comment By: Philipp Klaus Krause (spth) Date: 2012-02-22 07:58 Message: Fixed in revision #7324. Philipp ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=100599&aid=3490776&group_id=599 |
From: SourceForge.net <no...@so...> - 2012-02-29 16:55:44
|
Bugs item #3490776, was opened at 2012-02-22 01:00 Message generated for change (Comment added) made by spth You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=100599&aid=3490776&group_id=599 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: C Preprocessor Group: fixed Status: Open Resolution: Remind Priority: 5 Private: No Submitted By: Philipp Klaus Krause (spth) Assigned to: Philipp Klaus Krause (spth) Summary: Feature macros Initial Comment: sdcc does not provide complex types, variable-length arrays, multithreading and atomics. While this is allowed by the C11 standard (and with the exception of variable-length arrays by the C99 standard), implementations that do not provide these features have to define the __STDC_NO_COMPLEX__, __STDC_NO_VLA_, __STDC_NO_THREADS__ and __STDC_NO_ATOMICS__ macros. Philipp ---------------------------------------------------------------------- >Comment By: Philipp Klaus Krause (spth) Date: 2012-02-29 08:55 Message: For me cpp -dM < /dev/null only give 2 non-compliant macros: unix and linux. They go away when using --std=c99. Philipp ---------------------------------------------------------------------- Comment By: Borut Ražem (borutr) Date: 2012-02-29 08:52 Message: I would keep the sdcc behavior dependency on --std-xxx as low as possible, so I prefer to keep both versions of predefined macros regardless of --std-xxx setting. Just for example you can see the mess with gcc predefined macros by running cpp -dM < /dev.null: majority of macros is double uderlined, some are single underlined, some has both duble underlined and non uderlined versions, for example unix, __unix, __unix__ and linux, __linux, __linux__, ... But OTOH, your proposal is also not so bad idea. I would like to hear the opinion of other sdcc developers and specially sdcc users. Maybe we should open this discussion on sdcc-user mailing list. Borut ---------------------------------------------------------------------- Comment By: Philipp Klaus Krause (spth) Date: 2012-02-28 10:13 Message: I expect users of --std-c99 and --std-c89 to value standard compliance higher than backwards-compability. I would like to bring back the old macros for --std-sdcc89 (the current default) and --std-c99. Philipp P.S.: There are some port-specific macros that should be addressed, too. ---------------------------------------------------------------------- Comment By: Borut Ražem (borutr) Date: 2012-02-27 11:38 Message: I share Maarten's concerns about the change of predefined macros: it breaks the backward compatibility without giving the transition period to sdcc users. I propose to retain old SDCC_* macros and add new __SDCC_* alternative in the similar way we did it for non-double-underscored keywords. In the sdccman.lyx under chapter "1.4 Compatibility with previous versions" it should be stated that SDCC_* macros are deprecated in sdcc vesrion 3.2.0 and will be obsoleted (removed) in in one of next sdcc releases. Users shoud replace SDCC_* nacros with __SDCC_* macros in their code. I don't see how the user could be warned if he is using deprecated SDCC_* macros, but it wold be a nice feature... P.S.: non-double-underscored keywords are now obsoleted (removed), so the statement in chapter "1.4 Compatibility with previous versions": "special sdcc keywords which are not preceded by a double underscore are deprecated in version 3.0.0 and higher. See section ANSI-Compliance." should be replaced with "special sdcc keywords which are not preceded by a double underscore are obsoleted (removed) in version 3.2.0 and higher. See section ANSI-Compliance." Borut ---------------------------------------------------------------------- Comment By: Philipp Klaus Krause (spth) Date: 2012-02-26 06:59 Message: Hmm, where should we warn? In the preprocessor? Another option would be to bring back the old macro names when using --std-sdcc89 or --std-sdcc99 and marking them as deprecated in the documentation (which I should update for this change anyway). Philipp ---------------------------------------------------------------------- Comment By: Maarten Brock (maartenbrock) Date: 2012-02-26 00:34 Message: Philipp, With your fix for this item you've broken code for everyone depending on the documented predefined macros. And unless I missed it the compiler gives no warning to the user about it. I think we need to warn the user when we encounter something (macro-like?) that starts with 'SDCC'. Furthermore you forgot to update compiler.h which btw in my opinion needs to stay compiler version independent. Thus the check for 'SDCC' needs to stay but can be OR-ed with '__SDCC'. I have therefor reopened this item. ---------------------------------------------------------------------- Comment By: Philipp Klaus Krause (spth) Date: 2012-02-22 07:58 Message: Fixed in revision #7324. Philipp ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=100599&aid=3490776&group_id=599 |
From: SourceForge.net <no...@so...> - 2012-02-29 19:17:35
|
Bugs item #3490776, was opened at 2012-02-22 01:00 Message generated for change (Comment added) made by borutr You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=100599&aid=3490776&group_id=599 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: C Preprocessor Group: fixed Status: Open Resolution: Remind Priority: 5 Private: No Submitted By: Philipp Klaus Krause (spth) Assigned to: Philipp Klaus Krause (spth) Summary: Feature macros Initial Comment: sdcc does not provide complex types, variable-length arrays, multithreading and atomics. While this is allowed by the C11 standard (and with the exception of variable-length arrays by the C99 standard), implementations that do not provide these features have to define the __STDC_NO_COMPLEX__, __STDC_NO_VLA_, __STDC_NO_THREADS__ and __STDC_NO_ATOMICS__ macros. Philipp ---------------------------------------------------------------------- >Comment By: Borut Ražem (borutr) Date: 2012-02-29 11:17 Message: Just FYI there are 2 single underscored macross on gcc (Ubuntu/Linaro 4.6.1-9ubuntu3) 4.6.1, inependent of -std=xxx setting: #define _FORTIFY_SOURCE 2 #define _LP64 1 I didn't try to use -std=xxx in combination with cpp -dM < /dev/null. Now you showed that gcc is working in the similar way you proposed, your solution seems more acceptable to me. Borut ---------------------------------------------------------------------- Comment By: Philipp Klaus Krause (spth) Date: 2012-02-29 08:55 Message: For me cpp -dM < /dev/null only give 2 non-compliant macros: unix and linux. They go away when using --std=c99. Philipp ---------------------------------------------------------------------- Comment By: Borut Ražem (borutr) Date: 2012-02-29 08:52 Message: I would keep the sdcc behavior dependency on --std-xxx as low as possible, so I prefer to keep both versions of predefined macros regardless of --std-xxx setting. Just for example you can see the mess with gcc predefined macros by running cpp -dM < /dev.null: majority of macros is double uderlined, some are single underlined, some has both duble underlined and non uderlined versions, for example unix, __unix, __unix__ and linux, __linux, __linux__, ... But OTOH, your proposal is also not so bad idea. I would like to hear the opinion of other sdcc developers and specially sdcc users. Maybe we should open this discussion on sdcc-user mailing list. Borut ---------------------------------------------------------------------- Comment By: Philipp Klaus Krause (spth) Date: 2012-02-28 10:13 Message: I expect users of --std-c99 and --std-c89 to value standard compliance higher than backwards-compability. I would like to bring back the old macros for --std-sdcc89 (the current default) and --std-c99. Philipp P.S.: There are some port-specific macros that should be addressed, too. ---------------------------------------------------------------------- Comment By: Borut Ražem (borutr) Date: 2012-02-27 11:38 Message: I share Maarten's concerns about the change of predefined macros: it breaks the backward compatibility without giving the transition period to sdcc users. I propose to retain old SDCC_* macros and add new __SDCC_* alternative in the similar way we did it for non-double-underscored keywords. In the sdccman.lyx under chapter "1.4 Compatibility with previous versions" it should be stated that SDCC_* macros are deprecated in sdcc vesrion 3.2.0 and will be obsoleted (removed) in in one of next sdcc releases. Users shoud replace SDCC_* nacros with __SDCC_* macros in their code. I don't see how the user could be warned if he is using deprecated SDCC_* macros, but it wold be a nice feature... P.S.: non-double-underscored keywords are now obsoleted (removed), so the statement in chapter "1.4 Compatibility with previous versions": "special sdcc keywords which are not preceded by a double underscore are deprecated in version 3.0.0 and higher. See section ANSI-Compliance." should be replaced with "special sdcc keywords which are not preceded by a double underscore are obsoleted (removed) in version 3.2.0 and higher. See section ANSI-Compliance." Borut ---------------------------------------------------------------------- Comment By: Philipp Klaus Krause (spth) Date: 2012-02-26 06:59 Message: Hmm, where should we warn? In the preprocessor? Another option would be to bring back the old macro names when using --std-sdcc89 or --std-sdcc99 and marking them as deprecated in the documentation (which I should update for this change anyway). Philipp ---------------------------------------------------------------------- Comment By: Maarten Brock (maartenbrock) Date: 2012-02-26 00:34 Message: Philipp, With your fix for this item you've broken code for everyone depending on the documented predefined macros. And unless I missed it the compiler gives no warning to the user about it. I think we need to warn the user when we encounter something (macro-like?) that starts with 'SDCC'. Furthermore you forgot to update compiler.h which btw in my opinion needs to stay compiler version independent. Thus the check for 'SDCC' needs to stay but can be OR-ed with '__SDCC'. I have therefor reopened this item. ---------------------------------------------------------------------- Comment By: Philipp Klaus Krause (spth) Date: 2012-02-22 07:58 Message: Fixed in revision #7324. Philipp ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=100599&aid=3490776&group_id=599 |
From: SourceForge.net <no...@so...> - 2012-02-29 20:07:04
|
Bugs item #3490776, was opened at 2012-02-22 01:00 Message generated for change (Comment added) made by spth You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=100599&aid=3490776&group_id=599 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: C Preprocessor Group: fixed Status: Open Resolution: Remind Priority: 5 Private: No Submitted By: Philipp Klaus Krause (spth) Assigned to: Philipp Klaus Krause (spth) Summary: Feature macros Initial Comment: sdcc does not provide complex types, variable-length arrays, multithreading and atomics. While this is allowed by the C11 standard (and with the exception of variable-length arrays by the C99 standard), implementations that do not provide these features have to define the __STDC_NO_COMPLEX__, __STDC_NO_VLA_, __STDC_NO_THREADS__ and __STDC_NO_ATOMICS__ macros. Philipp ---------------------------------------------------------------------- >Comment By: Philipp Klaus Krause (spth) Date: 2012-02-29 12:07 Message: Single underscore followed by capital letter is allowed. However there are reasons why it is a bad choice and should not be used for new things (it is the namespace used for additions to the language, such as _Bool and _Noreturn). I think we have one such macro in sdcc, and I didn't change it. Philipp ---------------------------------------------------------------------- Comment By: Borut Ražem (borutr) Date: 2012-02-29 11:17 Message: Just FYI there are 2 single underscored macross on gcc (Ubuntu/Linaro 4.6.1-9ubuntu3) 4.6.1, inependent of -std=xxx setting: #define _FORTIFY_SOURCE 2 #define _LP64 1 I didn't try to use -std=xxx in combination with cpp -dM < /dev/null. Now you showed that gcc is working in the similar way you proposed, your solution seems more acceptable to me. Borut ---------------------------------------------------------------------- Comment By: Philipp Klaus Krause (spth) Date: 2012-02-29 08:55 Message: For me cpp -dM < /dev/null only give 2 non-compliant macros: unix and linux. They go away when using --std=c99. Philipp ---------------------------------------------------------------------- Comment By: Borut Ražem (borutr) Date: 2012-02-29 08:52 Message: I would keep the sdcc behavior dependency on --std-xxx as low as possible, so I prefer to keep both versions of predefined macros regardless of --std-xxx setting. Just for example you can see the mess with gcc predefined macros by running cpp -dM < /dev.null: majority of macros is double uderlined, some are single underlined, some has both duble underlined and non uderlined versions, for example unix, __unix, __unix__ and linux, __linux, __linux__, ... But OTOH, your proposal is also not so bad idea. I would like to hear the opinion of other sdcc developers and specially sdcc users. Maybe we should open this discussion on sdcc-user mailing list. Borut ---------------------------------------------------------------------- Comment By: Philipp Klaus Krause (spth) Date: 2012-02-28 10:13 Message: I expect users of --std-c99 and --std-c89 to value standard compliance higher than backwards-compability. I would like to bring back the old macros for --std-sdcc89 (the current default) and --std-c99. Philipp P.S.: There are some port-specific macros that should be addressed, too. ---------------------------------------------------------------------- Comment By: Borut Ražem (borutr) Date: 2012-02-27 11:38 Message: I share Maarten's concerns about the change of predefined macros: it breaks the backward compatibility without giving the transition period to sdcc users. I propose to retain old SDCC_* macros and add new __SDCC_* alternative in the similar way we did it for non-double-underscored keywords. In the sdccman.lyx under chapter "1.4 Compatibility with previous versions" it should be stated that SDCC_* macros are deprecated in sdcc vesrion 3.2.0 and will be obsoleted (removed) in in one of next sdcc releases. Users shoud replace SDCC_* nacros with __SDCC_* macros in their code. I don't see how the user could be warned if he is using deprecated SDCC_* macros, but it wold be a nice feature... P.S.: non-double-underscored keywords are now obsoleted (removed), so the statement in chapter "1.4 Compatibility with previous versions": "special sdcc keywords which are not preceded by a double underscore are deprecated in version 3.0.0 and higher. See section ANSI-Compliance." should be replaced with "special sdcc keywords which are not preceded by a double underscore are obsoleted (removed) in version 3.2.0 and higher. See section ANSI-Compliance." Borut ---------------------------------------------------------------------- Comment By: Philipp Klaus Krause (spth) Date: 2012-02-26 06:59 Message: Hmm, where should we warn? In the preprocessor? Another option would be to bring back the old macro names when using --std-sdcc89 or --std-sdcc99 and marking them as deprecated in the documentation (which I should update for this change anyway). Philipp ---------------------------------------------------------------------- Comment By: Maarten Brock (maartenbrock) Date: 2012-02-26 00:34 Message: Philipp, With your fix for this item you've broken code for everyone depending on the documented predefined macros. And unless I missed it the compiler gives no warning to the user about it. I think we need to warn the user when we encounter something (macro-like?) that starts with 'SDCC'. Furthermore you forgot to update compiler.h which btw in my opinion needs to stay compiler version independent. Thus the check for 'SDCC' needs to stay but can be OR-ed with '__SDCC'. I have therefor reopened this item. ---------------------------------------------------------------------- Comment By: Philipp Klaus Krause (spth) Date: 2012-02-22 07:58 Message: Fixed in revision #7324. Philipp ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=100599&aid=3490776&group_id=599 |
From: SourceForge.net <no...@so...> - 2012-03-19 16:26:36
|
Bugs item #3490776, was opened at 2012-02-22 01:00 Message generated for change (Comment added) made by spth You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=100599&aid=3490776&group_id=599 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: C Preprocessor Group: fixed Status: Open Resolution: Remind Priority: 5 Private: No Submitted By: Philipp Klaus Krause (spth) Assigned to: Philipp Klaus Krause (spth) Summary: Feature macros Initial Comment: sdcc does not provide complex types, variable-length arrays, multithreading and atomics. While this is allowed by the C11 standard (and with the exception of variable-length arrays by the C99 standard), implementations that do not provide these features have to define the __STDC_NO_COMPLEX__, __STDC_NO_VLA_, __STDC_NO_THREADS__ and __STDC_NO_ATOMICS__ macros. Philipp ---------------------------------------------------------------------- >Comment By: Philipp Klaus Krause (spth) Date: 2012-03-19 09:26 Message: About a week ago, I reenabled the old macros for --std-sdcc89 (the default) and --std-sdcc99. Philipp ---------------------------------------------------------------------- Comment By: Philipp Klaus Krause (spth) Date: 2012-02-29 12:07 Message: Single underscore followed by capital letter is allowed. However there are reasons why it is a bad choice and should not be used for new things (it is the namespace used for additions to the language, such as _Bool and _Noreturn). I think we have one such macro in sdcc, and I didn't change it. Philipp ---------------------------------------------------------------------- Comment By: Borut Ražem (borutr) Date: 2012-02-29 11:17 Message: Just FYI there are 2 single underscored macross on gcc (Ubuntu/Linaro 4.6.1-9ubuntu3) 4.6.1, inependent of -std=xxx setting: #define _FORTIFY_SOURCE 2 #define _LP64 1 I didn't try to use -std=xxx in combination with cpp -dM < /dev/null. Now you showed that gcc is working in the similar way you proposed, your solution seems more acceptable to me. Borut ---------------------------------------------------------------------- Comment By: Philipp Klaus Krause (spth) Date: 2012-02-29 08:55 Message: For me cpp -dM < /dev/null only give 2 non-compliant macros: unix and linux. They go away when using --std=c99. Philipp ---------------------------------------------------------------------- Comment By: Borut Ražem (borutr) Date: 2012-02-29 08:52 Message: I would keep the sdcc behavior dependency on --std-xxx as low as possible, so I prefer to keep both versions of predefined macros regardless of --std-xxx setting. Just for example you can see the mess with gcc predefined macros by running cpp -dM < /dev.null: majority of macros is double uderlined, some are single underlined, some has both duble underlined and non uderlined versions, for example unix, __unix, __unix__ and linux, __linux, __linux__, ... But OTOH, your proposal is also not so bad idea. I would like to hear the opinion of other sdcc developers and specially sdcc users. Maybe we should open this discussion on sdcc-user mailing list. Borut ---------------------------------------------------------------------- Comment By: Philipp Klaus Krause (spth) Date: 2012-02-28 10:13 Message: I expect users of --std-c99 and --std-c89 to value standard compliance higher than backwards-compability. I would like to bring back the old macros for --std-sdcc89 (the current default) and --std-c99. Philipp P.S.: There are some port-specific macros that should be addressed, too. ---------------------------------------------------------------------- Comment By: Borut Ražem (borutr) Date: 2012-02-27 11:38 Message: I share Maarten's concerns about the change of predefined macros: it breaks the backward compatibility without giving the transition period to sdcc users. I propose to retain old SDCC_* macros and add new __SDCC_* alternative in the similar way we did it for non-double-underscored keywords. In the sdccman.lyx under chapter "1.4 Compatibility with previous versions" it should be stated that SDCC_* macros are deprecated in sdcc vesrion 3.2.0 and will be obsoleted (removed) in in one of next sdcc releases. Users shoud replace SDCC_* nacros with __SDCC_* macros in their code. I don't see how the user could be warned if he is using deprecated SDCC_* macros, but it wold be a nice feature... P.S.: non-double-underscored keywords are now obsoleted (removed), so the statement in chapter "1.4 Compatibility with previous versions": "special sdcc keywords which are not preceded by a double underscore are deprecated in version 3.0.0 and higher. See section ANSI-Compliance." should be replaced with "special sdcc keywords which are not preceded by a double underscore are obsoleted (removed) in version 3.2.0 and higher. See section ANSI-Compliance." Borut ---------------------------------------------------------------------- Comment By: Philipp Klaus Krause (spth) Date: 2012-02-26 06:59 Message: Hmm, where should we warn? In the preprocessor? Another option would be to bring back the old macro names when using --std-sdcc89 or --std-sdcc99 and marking them as deprecated in the documentation (which I should update for this change anyway). Philipp ---------------------------------------------------------------------- Comment By: Maarten Brock (maartenbrock) Date: 2012-02-26 00:34 Message: Philipp, With your fix for this item you've broken code for everyone depending on the documented predefined macros. And unless I missed it the compiler gives no warning to the user about it. I think we need to warn the user when we encounter something (macro-like?) that starts with 'SDCC'. Furthermore you forgot to update compiler.h which btw in my opinion needs to stay compiler version independent. Thus the check for 'SDCC' needs to stay but can be OR-ed with '__SDCC'. I have therefor reopened this item. ---------------------------------------------------------------------- Comment By: Philipp Klaus Krause (spth) Date: 2012-02-22 07:58 Message: Fixed in revision #7324. Philipp ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=100599&aid=3490776&group_id=599 |
From: SourceForge.net <no...@so...> - 2012-05-16 13:35:24
|
Bugs item #3490776, was opened at 2012-02-22 01:00 Message generated for change (Comment added) made by spth You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=100599&aid=3490776&group_id=599 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: C Preprocessor Group: fixed >Status: Closed Resolution: Remind Priority: 5 Private: No Submitted By: Philipp Klaus Krause (spth) Assigned to: Philipp Klaus Krause (spth) Summary: Feature macros Initial Comment: sdcc does not provide complex types, variable-length arrays, multithreading and atomics. While this is allowed by the C11 standard (and with the exception of variable-length arrays by the C99 standard), implementations that do not provide these features have to define the __STDC_NO_COMPLEX__, __STDC_NO_VLA_, __STDC_NO_THREADS__ and __STDC_NO_ATOMICS__ macros. Philipp ---------------------------------------------------------------------- >Comment By: Philipp Klaus Krause (spth) Date: 2012-05-16 06:35 Message: Since there were no recent complaints wrt. this issue it seems everyone can live with the current compromise, so I close this issue. Philipp ---------------------------------------------------------------------- Comment By: Philipp Klaus Krause (spth) Date: 2012-03-19 09:26 Message: About a week ago, I reenabled the old macros for --std-sdcc89 (the default) and --std-sdcc99. Philipp ---------------------------------------------------------------------- Comment By: Philipp Klaus Krause (spth) Date: 2012-02-29 12:07 Message: Single underscore followed by capital letter is allowed. However there are reasons why it is a bad choice and should not be used for new things (it is the namespace used for additions to the language, such as _Bool and _Noreturn). I think we have one such macro in sdcc, and I didn't change it. Philipp ---------------------------------------------------------------------- Comment By: Borut Ražem (borutr) Date: 2012-02-29 11:17 Message: Just FYI there are 2 single underscored macross on gcc (Ubuntu/Linaro 4.6.1-9ubuntu3) 4.6.1, inependent of -std=xxx setting: #define _FORTIFY_SOURCE 2 #define _LP64 1 I didn't try to use -std=xxx in combination with cpp -dM < /dev/null. Now you showed that gcc is working in the similar way you proposed, your solution seems more acceptable to me. Borut ---------------------------------------------------------------------- Comment By: Philipp Klaus Krause (spth) Date: 2012-02-29 08:55 Message: For me cpp -dM < /dev/null only give 2 non-compliant macros: unix and linux. They go away when using --std=c99. Philipp ---------------------------------------------------------------------- Comment By: Borut Ražem (borutr) Date: 2012-02-29 08:52 Message: I would keep the sdcc behavior dependency on --std-xxx as low as possible, so I prefer to keep both versions of predefined macros regardless of --std-xxx setting. Just for example you can see the mess with gcc predefined macros by running cpp -dM < /dev.null: majority of macros is double uderlined, some are single underlined, some has both duble underlined and non uderlined versions, for example unix, __unix, __unix__ and linux, __linux, __linux__, ... But OTOH, your proposal is also not so bad idea. I would like to hear the opinion of other sdcc developers and specially sdcc users. Maybe we should open this discussion on sdcc-user mailing list. Borut ---------------------------------------------------------------------- Comment By: Philipp Klaus Krause (spth) Date: 2012-02-28 10:13 Message: I expect users of --std-c99 and --std-c89 to value standard compliance higher than backwards-compability. I would like to bring back the old macros for --std-sdcc89 (the current default) and --std-c99. Philipp P.S.: There are some port-specific macros that should be addressed, too. ---------------------------------------------------------------------- Comment By: Borut Ražem (borutr) Date: 2012-02-27 11:38 Message: I share Maarten's concerns about the change of predefined macros: it breaks the backward compatibility without giving the transition period to sdcc users. I propose to retain old SDCC_* macros and add new __SDCC_* alternative in the similar way we did it for non-double-underscored keywords. In the sdccman.lyx under chapter "1.4 Compatibility with previous versions" it should be stated that SDCC_* macros are deprecated in sdcc vesrion 3.2.0 and will be obsoleted (removed) in in one of next sdcc releases. Users shoud replace SDCC_* nacros with __SDCC_* macros in their code. I don't see how the user could be warned if he is using deprecated SDCC_* macros, but it wold be a nice feature... P.S.: non-double-underscored keywords are now obsoleted (removed), so the statement in chapter "1.4 Compatibility with previous versions": "special sdcc keywords which are not preceded by a double underscore are deprecated in version 3.0.0 and higher. See section ANSI-Compliance." should be replaced with "special sdcc keywords which are not preceded by a double underscore are obsoleted (removed) in version 3.2.0 and higher. See section ANSI-Compliance." Borut ---------------------------------------------------------------------- Comment By: Philipp Klaus Krause (spth) Date: 2012-02-26 06:59 Message: Hmm, where should we warn? In the preprocessor? Another option would be to bring back the old macro names when using --std-sdcc89 or --std-sdcc99 and marking them as deprecated in the documentation (which I should update for this change anyway). Philipp ---------------------------------------------------------------------- Comment By: Maarten Brock (maartenbrock) Date: 2012-02-26 00:34 Message: Philipp, With your fix for this item you've broken code for everyone depending on the documented predefined macros. And unless I missed it the compiler gives no warning to the user about it. I think we need to warn the user when we encounter something (macro-like?) that starts with 'SDCC'. Furthermore you forgot to update compiler.h which btw in my opinion needs to stay compiler version independent. Thus the check for 'SDCC' needs to stay but can be OR-ed with '__SDCC'. I have therefor reopened this item. ---------------------------------------------------------------------- Comment By: Philipp Klaus Krause (spth) Date: 2012-02-22 07:58 Message: Fixed in revision #7324. Philipp ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=100599&aid=3490776&group_id=599 |