• Fragment N1: GetBindingPtr() is a macro that assigns the argued variable.
• Fragment N2: we have our dedicated realloc() implementation that behaves differently than you assume (it bails out for errors).
• Fragment N3: CreateSymbolicLinkW() does return boolean, no data loss.
• Fragment N4: This is not an error like you commented, but I admit this is a bad habit.

Thank you for the report. I see no fatal errors. N4 is the only thing that I think worth fixing.

Shyouhei Urabe wrote:

• Fragment N1: GetBindingPtr() is a macro that assigns the argued variable.

It will cause no actual harm, but I think "if (bind && ...) {" seems pointless as OP said.

• Fragment N2: we have our dedicated realloc() implementation that behaves differently than you assume (it bails out for errors).

Really? It is realloc, not xrealloc. I cannot find a macro like "#define realloc ..." in win32/file.c.

• Fragment N3: CreateSymbolicLinkW() does return boolean, no data loss.

Then, I wonder why create_symbolic_link_func is declared so that it returns DWORD.

--
Yusuke Endoh [email protected]

Yusuke Endoh wrote:

• Fragment N2: we have our dedicated realloc() implementation that behaves differently than you assume (it bails out for errors).

Really? It is realloc, not xrealloc. I cannot find a macro like "#define realloc ..." in win32/file.c.

Yes, it isn't xrealloc, but table is a copy of cp->table and the original pointer is kept even when realloc failed.

Nobuyoshi Nakada wrote:

Yusuke Endoh wrote:

• Fragment N2: we have our dedicated realloc() implementation that behaves differently than you assume (it bails out for errors).

Really? It is realloc, not xrealloc. I cannot find a macro like "#define realloc ..." in win32/file.c.

Yes, it isn't xrealloc, but table is a copy of cp->table and the original pointer is kept even when realloc failed.

Sorry. I was wrong here.