Re: [Tinycc-devel] How to make TCC support utf8
lrd - On Thu, Jun 09, 2022 at 12:01:09PM +0800, lrt via Tinycc-devel wrote: > Who can tell me how to make TCC support utf8. > I want to use the Unicode API. Just .. don't. ‘Trojan Source’ Bug Threatens the Security of All Code November 1, 2021 https://krebsonsecurity.com/2021/11/trojan-source-bug-threatens-the-security-of-all-code/ (as seen on slashdot) - Larry ___ Tinycc-devel mailing list Tinycc-devel@nongnu.org https://lists.nongnu.org/mailman/listinfo/tinycc-devel
Re: [Tinycc-devel] Clarification about log message in commit 48df89e10e
Colleagues - On Thu, Apr 15, 2021 at 05:06:02PM +0200, Michael Matz wrote: > On Sun, 11 Apr 2021, Stefanos wrote: > > The following line in commit 48df89e10e confused me a bit: "don't use > > c99 in tcc (array designators etc.)" > > Which C version is being used in TCC's implementation, can you please > > clarify? > If you restrict yourself to c89 that would match the requirement. The > actual requirement is rather: "needs to be compilable with an old msvc". I'd generalize from that. Some of the many use cases for tcc are in the bootstrapping category: start from an old/substandard C compiler (e.g., old msvc, or mescc) to get a more modern/standard C compiler. The next step is sometimes using tcc to compile gcc-2.95.0 or gcc-4.7.4, which gets you a usable C++ compiler. Lots gets written on this topic. Here's one link, that prominently mentions TinyCC: https://bootstrappable.org/projects/mes.html - Larry ___ Tinycc-devel mailing list Tinycc-devel@nongnu.org https://lists.nongnu.org/mailman/listinfo/tinycc-devel
Re: [Tinycc-devel] It seem I pull code in wrong way. How can I revert it?
Pursuer - On Fri, Sep 11, 2020 at 11:27:05PM +0800, Pursuer wrote: > I'm sorry that I pull code in wrong way. > And now there are many commit like > Merge branch 'mob' of git://repo.or.cz/tinycc into mob > How can I remove them. Obligatory xkcd: https://xkcd.com/1597/ There are fancier (and arguably more efficient) ways to recover than "delete the project, and download a fresh copy". But they're harder to explain and understand. - Larry ___ Tinycc-devel mailing list Tinycc-devel@nongnu.org https://lists.nongnu.org/mailman/listinfo/tinycc-devel
Re: [Tinycc-devel] match formats and arguments exactly
Friends - On Fri, Jun 21, 2019 at 07:15:11PM +0200, Vincent Lefevre wrote: > On 2019-06-21 18:25:29 +0200, Ivo van Poorten wrote: > > clang/llvm. gcc is on its way out IMHO. Apple uses clang [...] Troll alert. :-) > Every compiler has its own benefits. That's why tcc still exists > in particular. :) Right. Wake me when clang can target MSP430 and microblaze. Adding RISC-V support to tcc would be _extremely_ interesting. Sorry about the armchair-quarterbacking; I can't offer any time for that project at the moment. - Larry ___ Tinycc-devel mailing list Tinycc-devel@nongnu.org https://lists.nongnu.org/mailman/listinfo/tinycc-devel
Re: [Tinycc-devel] c89
Edmund - On Wed, Sep 27, 2017 at 06:42:45AM +0100, Edmund Grimley Evans wrote: > > I went through the tcc compile with --std=c89 -pedantic and > > --std=c99 -pedantic options. That flagged the "long long" feature > > mentioned already, plus a bunch more potential barriers to strict > > c89 or even c99 compilers. > I'd be interested to see a list. Results of building tinycc (commit 8deb05c3e) with gcc-4.9.2 for x86_64 and adding --std=c89 -pedantic to CFLAGS. Short form: Output of $ grep warning makelog3.txt | sed -e 's/.*warning://' | sort -u invoking macro DEF_ASMTEST argument 2: empty macro arguments are undefined in ISO C90 and ISO C++98 ISO C90 does not support ‘long long’ [-Wlong-long] ISO C90 does not support the ‘ll’ gnu_printf length modifier [-Wformat=] ISO C90 doesn’t support unnamed structs/unions [-Wpedantic] ISO C90 forbids variable length array ‘_onstack’ [-Wvla] ISO C forbids assignment between function pointer and ‘void *’ [-Wpedantic] string length ‘1846’ is greater than the length ‘509’ ISO C90 compilers are required to support [-Woverlength-strings] string length ‘2492’ is greater than the length ‘509’ ISO C90 compilers are required to support [-Woverlength-strings] string length ‘6259’ is greater than the length ‘509’ ISO C90 compilers are required to support [-Woverlength-strings] type of bit-field ‘aligned’ is a GCC extension [-Wpedantic] type of bit-field ‘dllexport’ is a GCC extension [-Wpedantic] type of bit-field ‘dllimport’ is a GCC extension [-Wpedantic] type of bit-field ‘packed’ is a GCC extension [-Wpedantic] type of bit-field ‘unused’ is a GCC extension [-Wpedantic] type of bit-field ‘visibility’ is a GCC extension [-Wpedantic] type of bit-field ‘weak’ is a GCC extension [-Wpedantic] use of C99 long long integer constant [-Wlong-long] Long form, 1584 lines: download from http://recycle.lbl.gov/~ldoolitt/makelog3.txt d5c6874de25ee3c3db8b383c98374b18afa1d30529f9bcce163f26221a547477 makelog3.txt - Larry ___ Tinycc-devel mailing list Tinycc-devel@nongnu.org https://lists.nongnu.org/mailman/listinfo/tinycc-devel
Re: [Tinycc-devel] c89
Friends - On Tue, Sep 26, 2017 at 03:49:09PM -0700, Larry Doolittle wrote: > Someone asked about c89. I made a simple experiment on mob. > 1. Replace 67 //-style comments with /* */ > 2. #define inline __inline__ in tcc.h > 3. Use --std=c89 under gcc-4.9.2 on x86_64 > The result builds and passes self-tests. I went through the tcc compile with --std=c89 -pedantic and --std=c99 -pedantic options. That flagged the "long long" feature mentioned already, plus a bunch more potential barriers to strict c89 or even c99 compilers. Does someone have a concrete example of a c89 compiler they hope to boostrap from? Preferably one that can be downloaded and run (maybe in an emulator) without payment. For bootstrapping purposes, there are many workarounds that can be considered that might not fly for a production compiler. - Larry ___ Tinycc-devel mailing list Tinycc-devel@nongnu.org https://lists.nongnu.org/mailman/listinfo/tinycc-devel
[Tinycc-devel] c89
Friends - Someone asked about c89. I made a simple experiment on mob. 1. Replace 67 //-style comments with /* */ 2. #define inline __inline__ in tcc.h 3. Use --std=c89 under gcc-4.9.2 on x86_64 The result builds and passes self-tests. Note that by construction, this doesn't check tcc's non-x86_64 code generators. As much as I like c99, I could see an argument for putting step (1) above into mob. I can supply the patch to anyone interested, but I'm clearly not the right person to make that commit. - Larry ___ Tinycc-devel mailing list Tinycc-devel@nongnu.org https://lists.nongnu.org/mailman/listinfo/tinycc-devel
Re: [Tinycc-devel] Using tinycc for full source bootstrapping
On Sun, Sep 24, 2017 at 07:40:32PM +0200, grischka wrote: > Jan Nieuwenhuizen wrote: > >Are you willing to consider discussing/taking patches that reduce the > >variety and complexity of C constructs used in TinyCC source code? > >I have a list of about 20 unpolished patches[0] for constructs like: > I wonder which would be the smaller patch: The changes you propose > for tcc or a patch to support these constructs as is in the bootstrap > compiler. I wonder that too. I looked through a lot of the changes you made, and 99% of them decrease the code quality of tcc. IMHO the long-term path forward would be to improve your bootstrap compiler. The comma operator example you posted, that confused me at first, is an exception, and I just pushed a patch. Using semicolons here is more of a "say what you mean" and "principle of least surprise" approach to coding this function. The _other_ comma operators you found (and eliminated) in tcc's code base are used for all the right reasons, to reduce code duplication and create a smooth flow of control. I enthusiastically support boostrap projects in general, and wish you the best of luck going forward! Just don't expect mainline tcc to regress its code quality for your benefit. - Larry ___ Tinycc-devel mailing list Tinycc-devel@nongnu.org https://lists.nongnu.org/mailman/listinfo/tinycc-devel
[Tinycc-devel] spelling
Friends - I just committed a patch with 28 spelling fixes to mob. One word baffled me: in tcc.h I find the comment "next related symbol (for fields and anoms)" What are anoms? - Larry ___ Tinycc-devel mailing list Tinycc-devel@nongnu.org https://lists.nongnu.org/mailman/listinfo/tinycc-devel
Re: [Tinycc-devel] Using tinycc for full source bootstrapping
Friends - On Sun, Sep 24, 2017 at 12:27:17PM -0700, Larry Doolittle wrote: > On Sun, Sep 24, 2017 at 09:48:25AM +0200, Jan Nieuwenhuizen wrote: > > -p[0] = x & 255, p[1] = x >> 8 & 255; > The original line above, however, screams "I am a bug" to me. > The return value of "x & 255" is ignored, and it has no side effects, > so it can be discarded, leaving >p[0] = p[1] = x >> 8 & 255; > Is there any evidence it works? I tested it, and it does in fact work. Sorry, I got a little mixed up on the order of operations. Still, using comma there instead of semicolon seems needlessly confusing. It suggests that these were once tricky macro expansions instead of inline functions. If it were me I would use semicolon there (write32le()) and in write64le(). - Larry ___ Tinycc-devel mailing list Tinycc-devel@nongnu.org https://lists.nongnu.org/mailman/listinfo/tinycc-devel
Re: [Tinycc-devel] Using tinycc for full source bootstrapping
Friends - On Sun, Sep 24, 2017 at 09:48:25AM +0200, Jan Nieuwenhuizen wrote: > -p[0] = x & 255, p[1] = x >> 8 & 255; > +p[0] = x & 255; p[1] = x >> 8 & 255; I think the comma operator is an awesome part of the C standard, and sometimes permits much more clear and concise expression of process than would otherwise be possible. The original line above, however, screams "I am a bug" to me. The return value of "x & 255" is ignored, and it has no side effects, so it can be discarded, leaving p[0] = p[1] = x >> 8 & 255; Is there any evidence it works? - Larry ___ Tinycc-devel mailing list Tinycc-devel@nongnu.org https://lists.nongnu.org/mailman/listinfo/tinycc-devel
[Tinycc-devel] will touch memory past end of the struct
tinycc maintainers -
I know there's been a lot of work on bitfields lately.
Here's a stand-alone code snippet extracted from libgtk2.0-dev that triggers
one of the new warnings:
/usr/include/gtk-2.0/gtk/gtktable.h:99: warning: will touch memory past end of
the struct (internal limitation)
typedef unsigned int guint;
typedef unsigned short int guint16;
struct _GtkTableRowCol
{
guint16 requisition;
guint16 allocation;
guint16 spacing;
guint need_expand : 1;
guint need_shrink : 1;
guint expand : 1;
guint shrink : 1;
guint empty : 1;
};
I just wanted to make sure that this is the intended effect.
It seems to me that the structure would get at least 64 bits reserved
in memory, and the bitfields will naturally be manipulated without
referring to any memory beyond that.
- Larry
___
Tinycc-devel mailing list
Tinycc-devel@nongnu.org
https://lists.nongnu.org/mailman/listinfo/tinycc-devel
Re: [Tinycc-devel] tiny bit of lint
grischka -
On Tue, May 09, 2017 at 07:33:28PM +0200, grischka wrote:
> Yes, the configure warning magic doesn't work with clang. And
> hence my question was:
> Can you fix this?
> Means: recognize if $CC is clang and implement some method to
> disable its warnings in configure. Can you do this?
> That could be useful in future for similar problems.
Proof of concept, where dummy.c is something simple and correct like
int dummy(void) { return 0; }
CFLAGS="-Wall -g -O2"
cc=clang
W_OPTIONS="extra declaration-after-statement undef strict-prototypes
write-strings lskdjfsldfkj bogus no-pointer-sign no-sign-compare
no-unused-parameter no-string-plus-int"
$cc -c `for i in $W_OPTIONS; do echo -W$i; done` dummy.c > cc_msg.txt 2>&1
for i in $W_OPTIONS; do
O_INVALID=`grep -- -W$i cc_msg.txt)`
if test -z "$O_INVALID"; then CFLAGS="$CFLAGS -W$i"; fi
done
echo $CFLAGS
tcc has the interesting property that it accepts and ignores any -W flags
not on its (short) list, so even -Wlskdjfsldfkj -Wbogus are accepted by
the above process. gcc and clang reject them.
Tested, works with bash and dash.
- Larry
___
Tinycc-devel mailing list
Tinycc-devel@nongnu.org
https://lists.nongnu.org/mailman/listinfo/tinycc-devel
Re: [Tinycc-devel] tiny bit of lint
grischka - On Tue, May 09, 2017 at 05:44:28PM +0200, grischka wrote: > If people are going to use clang more likely, can't you add something > to configure for clang to turn off some silly warnings? > That would be USEFUL, for example ;) The clang flag to turn off this warning is -Wno-string-plus-int That brings up another issue, which is that tinycc's cute little configure script that figures out which warning (or lack of warning) flags are compatible with $CC doesn't work with clang. I have no opinion on whether adding the nice plural to two tinycc messages is worth the extra space and time. I don't think that ((i > 1) ? "s" : "") is a good choice. Any of "s" + (i<2), &"s"[i<2], and just a universal plural "symbols" (like it was before 2d3b9559 from Feb 2017) is fine with me. This is a lot of discussion for two lines of code. I guess that's mostly my fault, too. - Larry ___ Tinycc-devel mailing list Tinycc-devel@nongnu.org https://lists.nongnu.org/mailman/listinfo/tinycc-devel
Re: [Tinycc-devel] tiny bit of lint
Friends -
On Tue, May 09, 2017 at 11:49:23AM +0200, Christian Jullien wrote:
> Arf! You're right.
> That why I never fix warning in a code which is not mine.
> My fix proposal is definitively better.
Sorry, everyone, testing should have caught my original mistake.
I committed a fix.
The real equivalence is between the original "s" + (i<2)
and &"s"[i<2].
((i > 1) ? "s" : "") as suggested by Christian is perhaps easier
to for humans to understand, but (at least when compiling with tcc)
produces larger (by 20 bytes) and slower object code. With gcc -O2
the object code size penalty is 11 bytes. This is on x86_64, YMMV.
With that extra &, I can't really say the looks are improved over
the original. But testing with gcc (4.9.2), tcc, and clang (3.5.0)
they all get the right answer on both styles, and clang complains
about the original form.
- Larry
> -Original Message-
> From: Tinycc-devel [mailto:tinycc-devel-bounces+eligis=orange...@nongnu.org]
> On Behalf Of grischka
> Sent: mardi 9 mai 2017 10:26
> To: tinycc-devel@nongnu.org
> Subject: Re: [Tinycc-devel] tiny bit of lint
>
> Larry Doolittle wrote:
>
> @@ -965,7 +965,7 @@ static void pe_build_exports(struct pe_info *pe)
> } else {
> fprintf(op, "LIBRARY %s\n\nEXPORTS\n", dllname);
> if (pe->s1->verbose)
> -printf("<- %s (%d symbol%s)\n", buf, sym_count, "s" +
> (sym_count < 2));
> +printf("<- %s (%d symbol%s)\n", buf, sym_count, "s"[sym_count <
> 2]);
> }
> #endif
>
> And that is wrong of course.
>
> $ tcc examples/dll.c -shared -v
> ---> crash
>
> -- gr
>
> ___
> Tinycc-devel mailing list
> Tinycc-devel@nongnu.org
> https://lists.nongnu.org/mailman/listinfo/tinycc-devel
>
>
> ___
> Tinycc-devel mailing list
> Tinycc-devel@nongnu.org
> https://lists.nongnu.org/mailman/listinfo/tinycc-devel
___
Tinycc-devel mailing list
Tinycc-devel@nongnu.org
https://lists.nongnu.org/mailman/listinfo/tinycc-devel
Re: [Tinycc-devel] tiny bit of lint
grischka - On Mon, May 08, 2017 at 07:27:08PM +0200, grischka wrote: > Larry Doolittle wrote: > >I committed (to mob) one patch that should count as progress. > >Remove some unused-parameter lint > > In my book that counts as visual clutter with no practical benefit. > The opposite of "tinycc avoids the unnecessary". Suggesting particular > care that feels alien in contrast to what the code really cares about. I respect that point of view. Yes, the code is a bit more cluttered. In this case I added 11 lines of cruft to 9841 existing lines of code. Also note that this is source-only cruft, with no effect on the resulting binary. The potential upside, that I do value, is that (with a bit more work like this) "we" get to turn on -Wextra for general development. That _should_ lead to _real_ flaws getting caught earlier in the development cycle. If unused parameters in general are considered OK in this code base, CFLAGS could be set to -Wextra -Wno-unused-argument. The trick there would be in the configure/Makefile step, adding that flag set only on compatible compilers. I'll hold off doing anything more like this until and unless I hear a net positive from the mailing list. - Larry ___ Tinycc-devel mailing list Tinycc-devel@nongnu.org https://lists.nongnu.org/mailman/listinfo/tinycc-devel
Re: [Tinycc-devel] tiny bit of lint
Michael - On Mon, May 08, 2017 at 05:40:38AM +0200, Michael Matz wrote: > On Sun, 7 May 2017, Larry Doolittle wrote: > >Using gcc's -Wextra, I found 17 "unused parameter", > If the silencing really should happen (e.g. by void casting, as you > say) I have no big opinion on. I'd like to look at the possible > cleanup for internal functions first, though. I committed (to mob) one patch that should count as progress. Commit message: Remove some unused-parameter lint Mark TCCState parameter as unused in tcc_undefine_symbol(), tcc_add_symbol(), tcc_print_stats(), asm_get_local_label_name(), use_section1(), tccpp_delete(), tcc_tool_ar(), tcc_tool_impdef(), and tcc_tool_cross(). Also mark it unused in tcc_add_bcheck() unless CONFIG_TCC_BCHECK. Remove it entirely in ld_next(). I'm open to comments. - Larry ___ Tinycc-devel mailing list Tinycc-devel@nongnu.org https://lists.nongnu.org/mailman/listinfo/tinycc-devel
Re: [Tinycc-devel] Add support of musl-libc to tinycc
Michael - On Sun, May 07, 2017 at 08:16:08AM +0200, Michael Matz wrote: > On debian, if you have libc6-dev and musl-dev installed you get a > [mess that doesn't work with tinycc]. > So, yeah, the detection/support of musl > is early and doesn't work with the split-mind approach that debian > is using. > > It does work for the setup of musl as the main libc, like with > alpine linux; so I'm not sure the detection should be disabled or > rather be improved (or there should perhaps be a configure option to > override the detection by users). OK, sounds good, as long as improving the test results in it being disabled by default in debian and similar systems. I'd hate to see noobs discouraged from using this otherwise really nice code base by broken-ness caused by a false-positive musl detector. > >gcc-4.7.4/gcc/c-family/c-opts.c:141: error: ';' expected (got "=") > Yeah, thanks for finding the cause downthread. extern file-scope > declarations with initializer are questionable style but indeed > allowed by the standard, i.e. the above rejection is a bug in TCC. > Fixed in mob. Confirmed, awesome, thanks! - Larry ___ Tinycc-devel mailing list Tinycc-devel@nongnu.org https://lists.nongnu.org/mailman/listinfo/tinycc-devel
Re: [Tinycc-devel] Add support of musl-libc to tinycc
On Sat, May 06, 2017 at 08:54:45PM -0700, Larry Doolittle wrote: > I just made a quick attempt to build gcc-4.7.4 with current git tcc. > It made it through about 337 compiles before failing on > ../.././gcc/c-family/c-opts.c:141: error: ';' expected (got "=") Removing the bogus "extern" in that line makes the build progress quite far, enough to build and start running the first-stage gcc. The build fault that eventually occurs looks like it has nothing to do with tcc. I'd leave tcc alone, and just patch that bogus gcc source. The behavior difference between gcc and tcc simplifies to: $ cat ext_init.c extern const unsigned int c_family_lang_mask = 1; $ gcc -c ext_init.c ext_init.c:1:27: warning: ‘c_family_lang_mask’ initialized and declared ‘extern’ extern const unsigned int c_family_lang_mask = 1; ^ $ echo $? 0 $ tcc -c ext_init.c ext_init.c:1: error: ';' expected (got "=") $ echo $? 1 - Larry ___ Tinycc-devel mailing list Tinycc-devel@nongnu.org https://lists.nongnu.org/mailman/listinfo/tinycc-devel
Re: [Tinycc-devel] Add support of musl-libc to tinycc
Micheal, Marc, and tinycc lurkers - On Sun, May 07, 2017 at 04:54:38AM +0200, Michael Matz wrote: > On Thu, 20 Apr 2017, Marc Vertes wrote: > >I just committed the patch to support musl-libc in the tcc > >compiler development branch: http://repo.or.cz/w/tinycc.git > > [...] > >Dear tinycc developers, let me know if this feature can be added > >to the upcoming 0.9.27 version, and also how to fix the DLL > >bootstrap problem. > Fixed in mob. The problem is the stricter dynamic loader of musl, > which ignores all STB_LOCAL symbols for symbol resolution [...] > With that the tests also run on musl. [...] On Debian Jessie amd64 with musl-dev installed, tinycc (commit 5732a188) detects that musl exists (CONFIG_musl=yes in config.mak), builds OK, but fails on make test at dlltest: ./tcc2 -B.. -I/home/larry/git/tinycc/include -I/home/larry/git/tinycc -I.. -DCONFIG_TRIPLET="\"x86_64-linux-gnu\"" -DTCC_TARGET_X86_64 -DTCC_MUSL -DONE_SOURCE -run /home/larry/git/tinycc/tcc.c -B.. -I/home/larry/git/tinycc/include -I/home/larry/git/tinycc -I.. -run /home/larry/git/tinycc/examples/ex1.c /usr/lib/x86_64-linux-gnu/libc.so:2: error: unrecognized file type tcc: error: Unknown relocation type: 23 where $ cat /usr/lib/x86_64-linux-gnu/libc.so /* GNU ld script Use the shared library, but some functions are only in the static library, so try that secondarily. */ OUTPUT_FORMAT(elf64-x86-64) GROUP ( /lib/x86_64-linux-gnu/libc.so.6 /usr/lib/x86_64-linux-gnu/libc_nonshared.a AS_NEEDED ( /lib/x86_64-linux-gnu/ld-linux-x86-64.so.2 ) ) $ My personal recommendation is to disable musl detection in an 0.9.27 release, if that happens anytime soon. Other than the teething problems with musl support, the rest of tinycc works like a champ for me. The contrast between tinycc and gcc is astounding. I can build a tcc binary faster than I can unpack gcc-4.7.4 sources. I have long-term interest in tcc for use in diverse-double-compiling. I just made a quick attempt to build gcc-4.7.4 with current git tcc. It made it through about 337 compiles before failing on ../.././gcc/c-family/c-opts.c:141: error: ';' expected (got "=") - Larry ___ Tinycc-devel mailing list Tinycc-devel@nongnu.org https://lists.nongnu.org/mailman/listinfo/tinycc-devel
[Tinycc-devel] bug #50847: #line vs. #include "foo.h"
tinycc community -
I found and submitted tinycc bug #50847: #line directive corrupts #include
search path
https://savannah.nongnu.org/bugs/index.php?50847
Three comments:
1. The submission wraps the test case in a tidy (485 byte) tarball.
For lazyweb members who don't want to unpack that, there's really not
much to it. The bug is triggered by bad.c:
#line 10 "mythical.c"
#include "simple.h"
int foo(bar *b)
{ return b->x == b->y; }
where simple.h provides a typedef for bar, and the bug shows up
when bad.c is in a different directory from where you run the compile.
The command line in demo.sh is "tcc -c dir/bad.c".
2. The c99 standard is mute on where C compilers are supposed to find
their include files, but the gcc documentation is clear:
https://gcc.gnu.org/onlinedocs/gcc-3.0.2/cpp_2.html
GCC looks for headers requested with #include "file" first in the directory
containing the current file, then in the same places it would have looked for a
header requested with angle brackets. For example, if `/usr/include/sys/stat.h'
contains #include "types.h", GCC looks for `types.h' first in
`/usr/include/sys', then in its usual search path.
`#line' (see section 6. Line Control) does not change GCC's idea of the
directory containing the current file.
This is also the behavior of clang.
3. I put together a brain-dead patch to tinycc mob HEAD,
that touches three lines total and seems to do the job.
It is arguably somewhat wasteful of scratch memory.
Here it is, sorry if the mail pipeline mangles it:
diff --git a/libtcc.c b/libtcc.c
index 99bf783..302ce39 100644
--- a/libtcc.c
+++ b/libtcc.c
@@ -581,6 +581,7 @@ ST_FUNC void tcc_open_bf(TCCState *s1, const char
*filename, int initlen)
bf->buf_end = bf->buffer + initlen;
bf->buf_end[0] = CH_EOB; /* put eob symbol */
pstrcpy(bf->filename, sizeof(bf->filename), filename);
+pstrcpy(bf->filename2, sizeof(bf->filename2), filename);
#ifdef _WIN32
normalize_slashes(bf->filename);
#endif
diff --git a/tcc.h b/tcc.h
index 5b9d4a3..92b9060 100644
--- a/tcc.h
+++ b/tcc.h
@@ -546,6 +546,7 @@ typedef struct BufferedFile {
int *ifdef_stack_ptr; /* ifdef_stack value at the start of the file */
int include_next_index; /* next search path */
char filename[1024];/* filename */
+char filename2[1024];/* filename not modified by # line directive */
unsigned char unget[4];
unsigned char buffer[1]; /* extra size for CH_EOB char */
} BufferedFile;
diff --git a/tccpp.c b/tccpp.c
index 7e5cdcf..4495752 100644
--- a/tccpp.c
+++ b/tccpp.c
@@ -1791,7 +1791,8 @@ ST_FUNC void preprocess(int is_bof)
/* search in file's dir if "header.h" */
if (c != '\"')
continue;
-path = file->filename;
+/* https://savannah.nongnu.org/bugs/index.php?50847 */
+path = file->filename2;
pstrncpy(buf1, path, tcc_basename(path) - path);
} else {
___
Tinycc-devel mailing list
Tinycc-devel@nongnu.org
https://lists.nongnu.org/mailman/listinfo/tinycc-devel
[Tinycc-devel] configure file permission
Friends - commit 7acf9aa8 from earlier today took away the x (execute) permission bits on configure. That means the instructions in README ./configure make make test make install don't work any more. Just FYI, maybe you want to put those bits back, or update the README to say "sh configure". - Larry ___ Tinycc-devel mailing list Tinycc-devel@nongnu.org https://lists.nongnu.org/mailman/listinfo/tinycc-devel
Re: [Tinycc-devel] bug #50847: #line vs. #include "foo.h"
grischka - On Tue, Apr 25, 2017 at 09:20:53PM +0200, grischka wrote: > Larry Doolittle wrote: > >3. I put together a brain-dead patch to tinycc mob HEAD, > >that touches three lines total and seems to do the job. > >It is arguably somewhat wasteful of scratch memory. > Push to mob if you want it in the release. > (After all, if it works, and, what else could we do. I think I had > a quite similar patch somewhere, some (long) time ago.) OK, I seem to have followed the directions at http://repo.or.cz/tinycc.git successfully. I imagine a test case should be added to the source tree, but I haven't looked into that. - Larry ___ Tinycc-devel mailing list Tinycc-devel@nongnu.org https://lists.nongnu.org/mailman/listinfo/tinycc-devel
