Skip to contentSkip to conversation

Add (more) support for WIN32 attribute names

PATCH Applied Ramsay Jones 3 participants 4 messages May 22, 2007 – May 24, 2007 Sparse checker

lore
Share & tools
lore
#0 lore raw

PATCH 3/5 Add (more) support for WIN32 attribute names

In particular, the following identifiers (along with their __X__ variants) are now accepted as attribute names: fastcall, dllimport and dllexport. (cdecl and stdcall were added in baf2c5a84e by Michael Stefaniuc). For now, at least, these attributes are just ignored.

---
 ident-list.h |    7 +++++++
 parse.c      |    6 ++++++
 2 files changed, 13 insertions(+), 0 deletions(-)
ident-list.h +7 -0
index 7633a2f..d09c2ab 100644
@@ -70,6 +70,13 @@ IDENT(nonnull); IDENT(__nonnull); IDENT(__nonnull__);
 IDENT(__deprecated__);
 IDENT(__warn_unused_result__);
 
+/* WIN32 specific Attribute names */
+IDENT(cdecl); IDENT(__cdecl__);
+IDENT(stdcall); IDENT(__stdcall__);
+IDENT(fastcall); IDENT(__fastcall__);
+IDENT(dllimport); IDENT(__dllimport__);
+IDENT(dllexport); IDENT(__dllexport__);
+
 /* Preprocessor idents */
 __IDENT(pragma_ident, "__pragma__", 0);
 __IDENT(__VA_ARGS___ident, "__VA_ARGS__", 0);
parse.c +6 -0
index b74c7c0..db5c9e6 100644
@@ -327,6 +327,12 @@ static struct init_keyword {
 	{ "__cdecl__",	NS_KEYWORD,	.op = &ignore_attr_op },
 	{ "stdcall",	NS_KEYWORD,	.op = &ignore_attr_op },
 	{ "__stdcall__",	NS_KEYWORD,	.op = &ignore_attr_op },
+	{ "fastcall",	NS_KEYWORD,	.op = &ignore_attr_op },
+	{ "__fastcall__",	NS_KEYWORD,	.op = &ignore_attr_op },
+	{ "dllimport",	NS_KEYWORD,	.op = &ignore_attr_op },
+	{ "__dllimport__",	NS_KEYWORD,	.op = &ignore_attr_op },
+	{ "dllexport",	NS_KEYWORD,	.op = &ignore_attr_op },
+	{ "__dllexport__",	NS_KEYWORD,	.op = &ignore_attr_op },
 };
 
 void init_parser(int stream)
Signature · 1 line
1.5.1
#1 lore raw
Quoted 4 lines · Ramsay Jones

In particular, the following identifiers (along with their __X__ variants) are now accepted as attribute names: fastcall, dllimport and dllexport. (cdecl and stdcall were added in baf2c5a84e by Michael Stefaniuc). For now, at least, these attributes are just ignored.

Your patch seems to have some whitespace damage in the form of extra leading spaces. I've manually modified it to apply this time, but please figure out what causes these patches to break and fix it. You may want to test by sending patches to yourself and trying to apply them. I notice that you use Thunderbird; format=flowed may cause the problem, so try turning it off by disabling the preference mailnews.send_plaintext_flowed . You can do so either via Edit -> Preferences -> Advanced -> Config Editor; alternatively, if you have Enigmail installed, it offers a checkbox to turn off format=flowed in its preferneces.

- Josh Triplett

#2 lore raw
Quoted 10 lines · Josh Triplett

Your patch seems to have some whitespace damage in the form of extra leading spaces. I've manually modified it to apply this time, but please figure out what causes these patches to break and fix it. You may want to test by sending patches to yourself and trying to apply them. I notice that you use Thunderbird; format=flowed may cause the problem, so try turning it off by disabling the preference mailnews.send_plaintext_flowed . You can do so either via Edit -> Preferences -> Advanced -> Config Editor; alternatively, if you have Enigmail installed, it offers a checkbox to turn off format=flowed in its preferneces.

Indeed, all 5 patches have whitespace damage ;-(
Sorry for messing that up. I was under the (false) impression that I had knocked Thunderbird into submission on this issue; my git patch submissions had not been rejected, so I just assumed everything was OK. However, it appears that, after inspecting the git patch e-mails left in my sent folder, all my git patches have suffered the same problem. (ie Junio has been silently fixing them up! - oops).

After much study last night, it seems that the pattern of corruption is: for all lines that start with a space, insert an extra space, except for lines which consist of a single space, which is removed instead. 8-)

However, it seems that after setting "mailnews.send_plaintext_flowed" as you suggest above, the extra space is no longer being inserted. The elimination of the lone space is still happening, but git-apply seems to be OK with it!

I have regenerated the patch e-mails, done a "Save As" from the unsent folder, converted the resulting *.eml files to unix line ending and verified that they apply using:

    $ git apply --check --verbose --stat $patch-file

NOTE: git-apply will fail if the *.eml files have cr-lf line ending.

I hope you don't mind if I resend the e-mails to confirm they have been fixed. (I have removed the mailing-list from the cc:, so as not to spam the list)

By the way, the second patch did not reach the list, because it had three uppercase x chars in the subject and was bounced by the vger spam blocker ;-)

ATB,

Ramsay Jones

#3 lore raw
Quoted 7 lines · On Thu, 24 May 2007 16:59:03 +0100 Ramsay Jones wrote:

Indeed, all 5 patches have whitespace damage ;-(
Sorry for messing that up. I was under the (false) impression that I had knocked Thunderbird into submission on this issue; my git patch submissions had not been rejected, so I just assumed everything was OK. However, it appears that, after inspecting the git patch e-mails left in my sent folder, all my git patches have suffered the same problem. (ie Junio has been silently fixing them up! - oops).

Quoted 7 lines

After much study last night, it seems that the pattern of corruption is: for all lines that start with a space, insert an extra space, except for lines which consist of a single space, which is removed instead. 8-)

However, it seems that after setting "mailnews.send_plaintext_flowed" as you suggest above, the extra space is no longer being inserted. The elimination of the lone space is still happening, but git-apply seems to be OK with it!

This may help with tbird:
http://mbligh.org/linuxdocs/Email/Clients/Thunderbird

---
~Randy
*** Remember to use Documentation/SubmitChecklist when testing your code ***