I see what you mean. If the macro were substituted first, minus the backslashes, without considering the fact that the backslash is in the string literal, then it would not work. As I said, your suggestion works, but it is not the only way to do it. If in the substitution, the string literal is substituted as is, its backslash would remain. I do not have a strong preference how to do it. Shalom ________________________________ From: Alsop, Thomas R Sent: Thursday, December 06, 2007 7:13 PM To: Bresticker, Shalom; 'sv-bc@server.eda.org' Subject: RE: [sv-bc] Macro mantis proposals 1397 & 1478 Shalom, Here is what it states in 5.9: A string literal must be contained in a single line unless the new line is immediately preceded by a \ (back slash backslash). In this case, the back slash backslash and the new line are ignored You say that "if a macro definition contains a string literal with a backslash-newline, they both disappear, so that both the string literal and the macro definition continue", but I don't think that's possible given the statement above about string literals. Once the macro is "replaced" we must adhere to the string literal backslash rule above. If we have a string literal that continues to the next line the replaced macro code must have the backslash in it for that string literal. How is the compiler going to know that the string it's now seeing from the replaced macro used to have backslashes in it? This is what I started to allude to; that the only way to make this work would be to change the semantics such that string literals in macros that continued to the next line would _not_ have the backslash removed in the expanded/replaced text. Given that not many people ever look at replaced text, I opted to just remove both the backslash and the newline. -Tom ________________________________ From: Bresticker, Shalom Sent: Thursday, December 06, 2007 12:32 AM To: Alsop, Thomas R; sv-bc@server.eda.org Subject: RE: [sv-bc] Macro mantis proposals 1397 & 1478 Regarding 1397, I agree that your proposal looks like it would solve the problem, at the cost of changing the presence of newlines in expanded text, which would change line numbers. Alternately, a more conservative approach could point to 5.9 and point out that if a macro definition contains a string literal with a backslash-newline, they both disappear, so that both the string literal and the macro definition continue. Thanks, Shalom ________________________________ From: owner-sv-bc@server.eda.org [mailto:owner-sv-bc@server.eda.org] On Behalf Of Alsop, Thomas R Sent: Thursday, December 06, 2007 3:47 AM To: sv-bc@server.eda.org Subject: [sv-bc] Macro mantis proposals 1397 & 1478 Hi, There are 3 different mantis items that I know of that address this one paragraph in 21.5.1 `define. I am working on Mantis items 1397 and 1478 now and just want to give everyone a heads up on the direction I am taking thus far. Draft4 text: The macro text can be any arbitrary text specified on the same line as the text macro name. If more than one line is necessary to specify the text, the newline shall be preceded by a backslash ( \ ). The first newline not preceded by a backslash shall end the macro text. The newline preceded by a backslash shall be replaced in the expanded macro with a newline (but without the preceding backslash character). Mantis 1339 has been approved which adds the last sentence below: The macro text can be any arbitrary text specified on the same line as the text macro name. If more than one line is necessary to specify the text, the newline shall be preceded by a backslash ( \ ). The first newline not preceded by a backslash shall end the macro text. The newline preceded by a backslash shall be replaced in the expanded macro with a newline (but without the preceding backslash character). Any white space characters at the beginning or end of the macro text shall be removed. I am working on a proposal for Mantis issue 1397 - "LRM is unclear about multi-line string literal in text macro". Basically I am taking a very clean approach to resolving this issue by stating that both newlines and the escaped character are removed from the replaced macro text. This means that if anyone were to look at the replaced text, it's all going to be on the same line. I think it would be very rare or unusual that anyone would do this. Shalom says he has done this on occasion, but I think that proves my point:-):-) This change in the LRM implies that both a string literal and the macro text continue on the next line, which makes for a clean easy solution. The macro text can be any arbitrary text specified on the same line as the text macro name. If more than one line is necessary to specify the text, the newline shall be preceded by a backslash ( \ ). The first newline not preceded by a backslash shall end the macro text. The newline preceded by a backslash and the backslash shall both be removed in the expanded macro. replaced in the expanded macro with a newline (but without the preceding backslash character). I am also working on a proposal for Mantis issue 1478 - "nested macro definitions". Notice that I am adding "multi-line macro" so I can use it further on in the paragraph. I don't know if we already have another name for this. Also, I am not sure if I have to define "embedded" or if that is understood. I am also wondering if I should mention anything about the recursiveness of embedded macros. I think this is mentioned somewhere else. The macro text can be any arbitrary text specified on the same line as the text macro name. If more than one line is necessary to specify the text (i.e. a multi-line macro), the newline shall be preceded by a backslash ( \ ). The first newline not preceded by a backslash shall end the macro text. The newline preceded by a backslash shall be replaced in the expanded macro with a newline (but without the preceding backslash character). A multi-line macro may have an embedded macro, however the backslash continues the multi-line macro and not the embedded macro. If we combine all these Mantis items together we end up with the following. Let me know if this is going in the right direction. The macro text can be any arbitrary text specified on the same line as the text macro name. If more than one line is necessary to specify the text (i.e. a multi-line macro), the newline shall be preceded by a backslash ( \ ). The first newline not preceded by a backslash shall end the macro text. The newline preceded by a backslash and the backslash shall both be removed in the expanded macro. replaced in the expanded macro with a newline (but without the preceding backslash character). A multi-line macro may have an embedded macro, however the backslash continues the multi-line macro and not the embedded macro. Any white space characters at the beginning or end of the macro text shall be removed. Thanks, -Tom -- This message has been scanned for viruses and dangerous content by MailScanner <http://www.mailscanner.info/> , and is believed to be clean. --------------------------------------------------------------------- Intel Israel (74) Limited This e-mail and any attachments may contain confidential material for the sole use of the intended recipient(s). Any review or distribution by others is strictly prohibited. If you are not the intended recipient, please contact the sender and delete all copies. -- This message has been scanned for viruses and dangerous content by MailScanner, and is believed to be clean.Received on Thu Dec 6 10:18:43 2007
This archive was generated by hypermail 2.1.8 : Thu Dec 06 2007 - 10:18:54 PST