0

I'm looking for a way to insert an #undef to the lex generated source code that will appear before the built in lines lex generates.

When compiling a file.l with lex, I generate a lex.yy.c file. In my file.l I have written :

#include "y.tab.h"
#undef __STRICT_ANSI__
#include <string.h>

The #undef helps me compile the code under the flag -std=c99 So it needs to be done before including string.h. But the generated file includes string.h before copying my undef.

Without the #undef I am getting a lot of warnings due to the use of strdup. I have seen the normal fixes using flags, but like I said I can't access the makefile.

Adding 'manually' the line

#undef __STRICT_ANSI__

into lex.yy.c before fixes everything. But i prefer not to touch any of the generated code and have it done by lex.

I have read this, strdup(): Confused about warnings ('implicit declaration', 'makes pointer...without a cast', memory leak) And like i said it does solve it. But only if I can somehow force the generated file to run the undef first.

rici
  • 234,347
  • 28
  • 237
  • 341
Pichner
  • 5
  • 5
  • What stops you from modifying the Makefile? – rici Jun 30 '19 at 14:08
  • The notation with ‘`/#`’ is puzzling; I’d expect it to be a syntax error. The mention of `stdup` is presumably a typo for `strdup`. – Jonathan Leffler Jun 30 '19 at 14:08
  • If your problem is that there is no declaration for `strdup()` when compiling with option `-std=c99`, then the normal fix is to ensure you ask explicitly for the POSIX extensions to Standard C with a feature test macro. The simplest one is `#define _XOPEN_SOURCE 700`. Do this before including any POSIX header. Or compile with `-std=gnu99` which does this automatically. Or declare `strdup()` yourself so as to avoid the errors. There are probably other alternatives too. – Jonathan Leffler Jun 30 '19 at 14:18
  • For some reason u need authority to access make file. And yes the strdup is a typo. I appraciate the offer of using #define _XOPEN_SOURCE 700 but I forgot to mentioned that for some reason, the compiler doesn't react to that. it's like it's not even seeing it. There should be a lex library everything is included from, but I'm having a hard time accessing it – Pichner Jun 30 '19 at 14:23
  • Where did you get the makefile from? Probably, you can just change its permissions. – rici Jun 30 '19 at 14:24
  • The makefile is on a remote server, that server is running eclipse as well. And any change will require admin permissions. I have access to only run the code with the current setup + changing the files under a per determend File. I know this is not ideal... – Pichner Jun 30 '19 at 14:37
  • If that is provided by your school for students learning how to write parsers, you should ask the system administrator to add the feature-test macro setting to the Makefile. – rici Jun 30 '19 at 14:44
  • It's in the company I work for, the remote access is hidden behind a security layer... – Pichner Jul 02 '19 at 07:37
  • @pichner: maybe there's not much you can do about that, then, but you could still petition for the option of adding CPPFLAGS to the makefile. How fixed is the build procedure? Can you add other header files to the project? – rici Jul 02 '19 at 14:42

1 Answers1

2

To start with, #undef __STRICT_ASCII__ is not the correct way to enable the declaration of Posix functions like strdup.

Posix extensions which are declared in standard C library header files are made conditional on "feature test macros". You can read a summary in man feature_test_macros but in any case, the documentation for any function which requires a feature test macro includes a description of which macros are required. In the case of strdup, we can read in man strdup:

Feature Test Macro Requirements for glibc (see feature_test_macros(7)):

   strdup():
       _XOPEN_SOURCE >= 500

(Followed by more possibilities.)

Personally, I always use

#define _XOPEN_SOURCE 700

which requests declarations for all functions in the latest version of Posix.

One way to insert the feature test macro before any include of a standard library function is to do so on the compile command line:

-D_XOPEN_SOURCE=700

I like doing it this way, because I can add it to my Makefile and then it applies to every compilation (which is basically what I want). Usually, makefiles include a feature which allows you to add this option to your compiler flags without modifying the file. For example, the following will often work:

make file CPPFLAGS="-D_XOPEN_SOURCE=700"

(CPPFLAGS is a common makefile variable used to set preprocessor flags.)

But if you want to put it into your flex file, you can use a %top block:

%top {
#define _XOPEN_SOURCE 700
}

%top is like %{ but it puts the inserted code right at the beginning of the generated code.


If nothing else works, you can always just insert the declaration for strdup, (also taken from man strdup) into your flex prologue.

%{
  char *strdup(const char *s);
  #include "y.tab.h"
%}

Both the C standard and the Posix standard allow explicit declaration of library functions (but not macros) as an alternative to including relevant headers.

rici
  • 234,347
  • 28
  • 237
  • 341
  • First of all let me thank you for the response, the declaration of 'strdup' did in fact work. I read somewhere that doing so is not a common fix, and doing so is considered 'messy'. But in fact everything failed except that. So thank you :) – Pichner Jul 02 '19 at 07:40
  • @pichner: I agree that it is a messy fix, but if you have no control over your build procedure then your alternatives are limited. I'd put a comment in the code explaining that reason. – rici Jul 02 '19 at 14:37