C cleanups

[ronnychevalier]

Another batch of cleanups for the C code in tectonic/.

[pkgw]

Ooh, you've probably been using this for a while, but I wasn't aware of coccinelle until I read your commit messages. Neat! And, thanks for documenting what you've done. I think coccinelle could be extremely useful for some higher-level transforms of the C code ... it probably would have saved me a lot of work in earlier iterations! Hopefully it can help transform the C code that accesses TeX's structures to allow us to get rid of all of the mem[q].hh.u.B0 type constructs.

I see that you've added some inline functions. Are there any portability dangers associated with this? For the time, I only care about vaguely recent Linux, OSX, and Windows, so I don't mind if inline functions are only going to cause problems on old versions of AIX or whatever.

I am not a huge fan of the function name streq_ptr ... is there a special reasoning to the naming? Please note that there is already a #define called STREQ that does the same thing ... if the inline function is nice and portable, I would definitely prefer to switch to it to get type-safety etc. But maybe just call it streq? Is that name used on some OS's?

And for consistency with other functions, I think I might prefer renaming startswith to strstartswith.

[ronnychevalier]

On 20/06/2017 04:28, Peter Williams wrote: Ooh, you've probably been using this for a while, but I wasn't aware of coccinelle until I read your commit messages. Neat! And, thanks for documenting what you've done. I think coccinelle could be *extremely* useful for some higher-level transforms of the C code ... it probably would have saved me a lot of work in earlier iterations! Hopefully it can help transform the C code that accesses TeX's structures to allow us to get rid of all of the |mem[q].hh.u.B0| type constructs.

Yes, it's a great tool and will be useful for more cleanups in the future :)

I see that you've added some |inline| functions. Are there any portability dangers associated with this? For the time, I only care about vaguely recent Linux, OSX, and Windows, so I don't mind if inline functions are only going to cause problems on old versions of AIX or whatever.

The only portability issue that comes to mind would be that it requires C99. I don't think that is an issue. All recent compilers support C99 and all recent operating systems have a compiler supporting C99. Also, if we want to improve the quality of the code I don't think we should restrain ourself to C89.

I am not a huge fan of the function name |streq_ptr| ... is there a special reasoning to the naming? Please note that there is already a |#define| called |STREQ| that does the same thing ... if the inline function is nice and portable, I would definitely prefer to switch to it to get type-safety etc. But maybe just call it |streq|? Is that name used on some OS's?

It is called that way because it NULL-checks the pointers, and it checks if they are equal. An `streq` function would be when you are sure that the pointers are not NULL, it would only use strcmp without NULL-checking. In this case I used a conservative approach and considered that we should check for the pointers each time. We might use a function that do not check the pointers later if we find some. In addition, I am used to the naming of some functions from the systemd project, so that's why I reused such name I guess. And since it differentiates a function that NULL-checks the pointer or not, I think it is appropriate. Do you still want me to change to streq? Also, like you said I removed the macro because it adds some type information (and also because I think non-uppercase functions and macro acting as a function is nicer to look at :)

And for consistency with other functions, I think I might prefer renaming |startswith| to |strstartswith|.

Sure

[ronnychevalier]

Also, what's the purpose of mem[q].hh.u.B0?

[pkgw]

• OK, if inline is specified in C99, I'm happy to use it. There's a part of me that still feels a little uncomfortable using some C99 constructs, but seriously, the standard is almost 20 years old at this point. The discomfort says more about when I started learning C (before 1999!) than it does about what's portable.
• Thanks for explaining the _ptr suffix. I can't say that it feels especially "right" to me, but it's fine to keep the function with the suffix as-is. For what it's worth I have the impression that systemd has lots of careful, clean C code, so if the suffix is coming from their style that genuinely encourages me to give it a try.
• Accesses like mem[q].hh.u.B0 are basically accesses to fields of the various structures used by the TeX engine. TeX manages memory manually by manipulating "pointers" (offsets) within its big loosely-typed mem array. Most of these pointers are to data structures with named fields but because of the way the WEB2C translation works, unfortunately the symbolic information was all lost in the translation to C. I'd really like to make all of these references symbolic again, but I have trouble seeing how to make the change incrementally, which means it would be a very big project.