On 05/09/2013 05:19 AM, Bruce Tulloch wrote:
This tells me that the test at the top of fpc_AnsiStr_Decr_Ref:
cmpl $0,(%eax)
jne .Ldecr_ref_continue
ret
.Ldecr_ref_continue:
passed (i.e. (%eax) was NOT nil) but sometime during the execution of
the following
In our previous episode, waldo kitty said:
i did even have 2.6.0 or 2.6.2 but decided that was not good even
though it may be supported...
2.6.0 is currently only supported for now. It might be removed sooner or
later.
earlier in the thread someone posted that 2.6.2 could be
Marco van de Voort wrote:
In our previous episode, waldo kitty said:
i did even have 2.6.0 or 2.6.2 but decided that was not good even
though it may be supported...
2.6.0 is currently only supported for now. It might be removed sooner or later.
earlier in the thread someone posted that 2.6.2
In our previous episode, Mark Morgan Lloyd said:
Would it be possible to query the makefile to get the required compiler
version etc.? Something like
$ make version
This is Free Pascal version 2.7.1, release 123456.
The only compiler version supported by the build procedure is 2.6.2.
IMHO
El 09/05/2013 5:19, Bruce Tulloch escribió:
If there is no other explanation, then it means I need to find out how
the string variable referred to by (%eax) could have been been accessed
(or even known to exist) by any other thread in the same address space.--
Hello,
In the past I had
Thanks Ludo, but I know the value in (%eax) in this case is nil (see the
cpu register dump in my email) because the address of the string length (in
edx) is 0xfff8 (which is 8 less than nil) per the instruction just
before the one that fails with SEGV. The SEGV itself is caused by an
attempt
Thanks José, I can see that might cause a problem given bar passes result
by reference to foo without initializing result first. My question to Jonas
or others more knowledgeable than me about what the compiler does, is
whether result (in your example and my own case) is guaranteed to be
On 09 May 2013, at 14:39, Bruce Tulloch wrote:
Thanks José, I can see that might cause a problem given bar passes result
by reference to foo without initializing result first. My question to Jonas
or others more knowledgeable than me about what the compiler does, is
whether result (in your
On 09.05.2013 14:39, Bruce Tulloch wrote:
Thanks José, I can see that might cause a problem given bar passes
result by reference to foo without initializing result first. My
question to Jonas or others more knowledgeable than me about what the
compiler does, is whether result (in your example
Hello listers,
I friend has sent me a component to read and write mp3 tags. In
particular, I am interested in the ID3v2 pattern.
In theory, the attatched component could do what I want. I can't make
sure, but I think it is not working very well.
When I use ID3v1 tags, title, artist, album,
As wikipedia explains, ID3v1 and ID3v2 are completely unrelated and have
different structure. Without seeing what your friend unit contains, it's
hard to tell whether he implements both versions correctly or not. But since
you said the version 1 works, and I don't see anything discriminating the
Well, the unit you present me seems to only support ID3v1.
I said: It works only under the ID3v1 pattern! No. Its not correct.
What I want to say is that only the same tags filled under the ID3v1
pattern is filled when I use the TID3v2 class. So the attached unit
and the mentioned example behaves
Well, the unit you present me seems to only support ID3v1.
I said: It works only under the ID3v1 pattern! No. Its not correct.
What I want to say is that only the same tags filled under the ID3v1
pattern is filled when I use the TID3v2 class. So the attached unit
and the mentioned example behaves
Well, the unit you present me seems to only support ID3v1
Have you really checked and tried the code? It works for both version.
--
View this message in context:
http://free-pascal-general.1045716.n5.nabble.com/ID3v2-Reading-and-writing-MP3-metadata-tp5714707p5714711.html
Sent from the Free
I didn't test it becose I didn't find the composer tag in the source
code. Without the composer tag, I can conclude it does not support
ID3V2.
I observed also that genre is an integer. At ID3v2, genre became a string.
2013/5/9, Fred van Stappen fi...@hotmail.com:
Well, the unit you present me
The compiler turns such functions into procedures with an implicit
var-parameter
and the *caller* passes the location where the function result should go
via that
parameter.
Okay, thanks, that clarifies, now I understand how a variable in the
caller's scope can be affected while making
16 matches
Mail list logo
