0x1a / 26 / Ctrl+Z is the old DOS EOF character:
https://en.wikipedia.org/wiki/Substitute_character
Was this file opened in text mode? See the MSDN documentation for
_fopen() for details, mode "t".
On 06/22/2015 09:09 AM, Etienne Sandré-Chardonnal wrote:
> No, that's a zlib compressed binary.
>
Edward Diener
writes:
> My usage of mingw-64 might be to only compile, or to compile/link,
> without the need to run anything immediately.
You must admit that this type of usage is not common.
[snip]
> Furthermore with multiple toolchains your method of adding the
> toolchains bin directory
On 6/22/2015 8:17 PM, Óscar Fuentes wrote:
> Edward Diener
> writes:
>
>>> Maybe your frustration does not allow you to understand what I wrote.
>>> Please read it again. I expect some difficulty with the concept of
>>> having multiple installs of the toolset, with varying versions and
>>> configu
Edward Diener
writes:
>> Maybe your frustration does not allow you to understand what I wrote.
>> Please read it again. I expect some difficulty with the concept of
>> having multiple installs of the toolset, with varying versions and
>> configurations, but there is no excuse for not understandin
On 6/23/2015 07:32, Edward Diener wrote:
>>
>> Maybe your frustration does not allow you to understand what I wrote.
>> Please read it again. I expect some difficulty with the concept of
>> having multiple installs of the toolset, with varying versions and
>> configurations, but there is no excuse
On 6/22/2015 4:50 PM, Óscar Fuentes wrote:
> Edward Diener
> writes:
>
>>> As I mentioned on other message on this thread, you must set PATH
>>> anyways for executing the resulting binaries of your compilation. There
>>> is no possible workaround for this, other than installing libwinpthread,
>>>
Hi,
There have been concerns on various places on the Internet that the
download page on the mingw-w64 website at
http://mingw-w64.org/doku.php/download is not consistently kept
up-to-date. The website is a simple and friendly wiki with open
registration and if/when mingw-w64 moves away from sourc
Edward Diener
writes:
>> As I mentioned on other message on this thread, you must set PATH
>> anyways for executing the resulting binaries of your compilation. There
>> is no possible workaround for this, other than installing libwinpthread,
>> libstdc++ and co. on a directory that already is on
Edward,
I'm really flashed about the enormous patience and tolerance from this
community.
However, you may or may not noticed, that there are different builds with
configurations for mingw-w64 based toolchains available.
What you need for your purpose is a toolchain that is based on statically
l
On 6/22/2015 12:02 PM, Óscar Fuentes wrote:
> Edward Diener
> writes:
>
>>> Apparently those programmers are not so inconvenienced as you are by
>>> having to use methods like the .bat mentioned above. And I can assure
>>> you that some of those programmers have quite a few gcc installs on
>>> the
Op 22-jun.-2015 19:48 schreef "LRN" :
>
> On 22.06.2015 19:09, Etienne Sandré-Chardonnal wrote:
> > On 2015-06-22 17:21 GMT+02:00 LRN wrote:
> >> On 22.06.2015 17:25, Etienne Sandré-Chardonnal wrote:
> >>> Hi,
> >>>
> >>> Without eof, it still returns 262 bytes which is wrong.
> >> That's a very ar
On 22.06.2015 19:09, Etienne Sandré-Chardonnal wrote:
> On 2015-06-22 17:21 GMT+02:00 LRN wrote:
>> On 22.06.2015 17:25, Etienne Sandré-Chardonnal wrote:
>>> Hi,
>>>
>>> Without eof, it still returns 262 bytes which is wrong.
>> That's a very arbitrary number. Is the file opened in binary mode? Any
No, that's a zlib compressed binary.
Starting from offset 0x100 (256):
f7 ce 21 7c 5b b1 1a d7 a6 67 a2 55 e2 22 4e 88
Byte 262 is 0x1a (26)
2015-06-22 17:21 GMT+02:00 LRN :
> On 22.06.2015 17:25, Etienne Sandré-Chardonnal wrote:
> > Hi,
> >
> > Without eof, it still returns 262 bytes which is
Edward Diener
writes:
>> Apparently those programmers are not so inconvenienced as you are by
>> having to use methods like the .bat mentioned above. And I can assure
>> you that some of those programmers have quite a few gcc installs on
>> their machines, that they use on a regular basis.
>
> Yo
On 6/21/2015 10:43 PM, Óscar Fuentes wrote:
> Edward Diener
> writes:
>
>>> At the end, adapting your PATH setting works the best. Just a simple
>>> .bat file solves the problem for those of us that need to constantly
>>> experiment with multiple installs:
>>>
>>> @rem mingw-w64-492.bat
>>> @PATH=
On 22.06.2015 17:25, Etienne Sandré-Chardonnal wrote:
> Hi,
>
> Without eof, it still returns 262 bytes which is wrong.
That's a very arbitrary number. Is the file opened in binary mode? Anything
significant around the 262th byte in the file contents?
--
O< ascii ribbon - stop html email! - www.
Hi,
Without eof, it still returns 262 bytes which is wrong.
I ended up writing my own streambuf reading from a FILE* and this now
returns the proper value (around 40MB)
The custom streambuf is based on this :
http://www.mr-edd.co.uk/blog/beginners_guide_streambuf
There is definitely a bug in thi
2015-06-22 13:21 GMT+02:00 Etienne Sandré-Chardonnal :
> Hi,
>
> I have tried to open the file with _wfopen(), pass it to __gnu_cxx::
> stdio_filebuf, and set it as the buffer of an std::istream.
> The file is open properly, first bytes are OK, but after 263 read bytes I
> get an eof(), while the
JonY writes:
> This. This is the reason why it was never changed, because it was never
> seen as a problem, its just something you did.
>
> I setup PATH depending on which compiler version I want to use, all
> sharing the same mingw-w64 install, courtesy of hardcoded paths.
And anyways you need
Hi,
I have tried to open the file with _wfopen(), pass it to __gnu_cxx::
stdio_filebuf, and set it as the buffer of an std::istream.
The file is open properly, first bytes are OK, but after 263 read bytes I
get an eof(), while the file is 39MB large.
Reading works well with a standard std::ifstr
On 6/22/2015 10:43, Óscar Fuentes wrote:
>>
>> I am surprised that such good programmers should understand so little
>> about producing a self-enclosed installation of mingw-64 ( or mingw ) to
>> the point of not being able to create a distribution that just works
>> automatically when any execu
21 matches
Mail list logo
