I have some code looking like this
long a;
long int c;

that I like to have transformed into
SInt32 a;
SInt32 c;

so I write
/long/ {
  gsub(/\<long\>[ /t]*(\<int\>)*/, "SInt32 ");
  }

but if the code says
long time;

it becomes
SInt32 ime;

How do I specifies that if there is a "int" afterwards, it should be
converted, but if its 'i', 'n' or 't' nothing should happens

Of course I can do this ( and have done, but how to write on one line!
(having trouble with "signed" in front too, but I guess it should be the
same cure!))
/long/ {
  gsub(/\<long\>[ /t]*\<int\>/, "SInt32 ");
  gsub(/\<long\>/, "SInt32 ");
  }

best regards
    Torben

John.

Tanks for the help ...

Found out that I should not do a "replace all", eg.

char a[]="char";
should become
SInt8 a[]="char";

This I haven done before, any ideas on how to do this, can I still use gsub?
or ?

best regards
    Torben

% Found out that I should not do a "replace all", eg.
%
% char a[]="char";
% should become
% SInt8 a[]="char";

For both your problems, it's probably easier not to try some complicated
regular expression. For one thing, awk uses `extended' regular expressions,
which are frankly a bit limited when compared to `basic' regular
expressions. For instance, \<long\> is not really valid in an awk RE. It
works with gawk, but probably not with any of the others, and it will
fail with gawk if you use the --posix flag.

awk breaks input lines into fields, and you can use this to your advantage:

 /long/ {
   if ($1 == "long") $1 = "int32_t"
   else if ($1 ~ "^(un)?signed$" && $2 == "long") $2 = "int32_t"
   # we don't expect other cases...
 }

 /char/ {
   if ($1 == "char") $1 = "uint8_t"
   else if ($1 ~ "^(un)?signed$" && $2 == "char") $2 = "int8_t"
   # we don't expect other cases...
 }

(From a C perspective, I recommend using the types defined in stdint.h
 to ensure portability -- if they're not defined by your current compiler,
 look for inttypes.h, which was the original proposed name, and which
 includes stdint.h in the standard, and failing that, you might as well
 make your own type definitions match the ones in the standard, since
 it will prevent your having to create new definitions for new machines
 which do follow the standard).
--

Patrick TJ McPhee
East York  Canada