| Age | Commit message (Collapse) | Author |
|---|
|
Go 1.22 now support for-range on numeric value.
|
|
Since Go 1.20, the standard bytes package have the Copy function.
Since Go 1.22, the standard slices package have the Concat function.
|
|
|
|
Previously, we use ParseInt to parse escaped octet "\NNN", but using
this method only allow decimal from 0 to 127, while the specification
allow 0 to 255.
|
|
HTTP request now implicitly create request with context.
Any false positive related to not closing HTTP response body has been
annotated with "nolint:bodyclose".
In the example code, use consistent "// Output:" comment format, by
prefixing with single space.
Any comment on code now also prefixing with single space.
An error returned without variables now use [errors.New] instead of
[fmt.Errorf].
Any error returned using [fmt.Errorf] now wrapped using "%w" instead of
"%s".
Also, replace error checking using [errors.Is] or [errors.As], instead
of using equal/not-equal operator.
Any statement like "x = x OP y" now replaced with "x OP= y".
Also, swap statement is simplified using "x, y = y, x".
Any switch statement with single case now replaced with if-condition.
Any call to defer on function or program that call [os.Exit], now
replaced by calling the deferred function directly.
Any if-else condition now replaced with switch statement, if possible.
|
|
There are several reasons that why we move from github.com.
First, related to the name of package.
We accidentally name the package with "share" a common word in English
that does not reflect the content of repository.
By moving to other repository, we can rename it to better and unique
name, in this "pakakeh.go".
Pakakeh is Minang word for tools, and ".go" suffix indicate that the
repository related to Go programming language.
Second, supporting open source.
The new repository is hosted under sourcehut.org, the founder is known
to support open source, and all their services are licensed under AGPL,
unlike GitHub that are closed sources.
Third, regarding GitHub CoPilot.
The GitHub Terms of Service [1], allow any public content that are hosted
there granted them to parse the content.
On one side, GitHub helps and flourish the open source, but on another
side have an issues regarding scraping the copyleft license [2].
[1]: https://docs.github.com/en/site-policy/github-terms/github-terms-of-service#4-license-grant-to-us
[2]: https://githubcopilotinvestigation.com
|
|
Previously, the zoneParser store its own origin and TTL, which make it
duplicates and confuse with the zone field that stored and returned by
parser.
To make things simple, use the zone field value as single source of
truth for origin (using zone.Origin) and TTL (using zone.SOA.Minimum).
|
|
One of the property that we seems forget that the Origin actually
must be absolute domain, end with period.
If user does not know this, they may call NewZone or define $ORIGIN
in zone file with relative domain.
|
|
Any call to Zone Add or Remove methods will update the Zone.SOA.Serial to
current epoch.
|
|
Previously, to check if string value is valid record class or type, we
use a function that iterate each map key and return a boolean.
This changes simplify it by getting the map RecordClasses and RecordTypes
value directly.
|
|
Using global debug value for all packages turns out is not a good
idea.
|
|
Due to refactoring in c376eccd25, parsing SOA record with single line
return an error: "parseSOA: line 2: incomplete SOA statement '0'".
|
|
The libio.Reader will be deprecated and replaced with libbytes.Parser
in the future.
|
|
Even thought the MINFO record not formally obsolete, according to
Wikipedia [1], we still need to support this for backward compatibility.
When packing the resource data length does not include total length.
When parsing, the RMailBox and EmailBox should be added the origin suffix
if its not end with dot.
When saving, the origin should be trimmed from RMailBox and EmailBox.
[1] https://en.wikipedia.org/wiki/List_of_DNS_record_types#Obsolete_record_types
|
|
Previous parseSRV start by parsing the _Service from tok, but the
actual value of parameter tok is the Priority.
This changes fix this and as testing we use the example from RFC 2782.
|
|
Previously, the zone only parsing TXT record with double quote since
most of the example that we found during implementation all use double
quote.
This changes allow non-double quoted text in zone file with consequence
that any spaces will terminated the rdata immediately.
Fixes #6
|
|
A character-string is expressed in one or two ways: as a contiguous set of
characters without interior spaces, or as a string beginning with a " and
ending with a ".
For contiguous string without double quotes, the following encoding are
recognized,
- \X where X is any character other than a digit (0-9), is used to quote
that character so that its special meaning does not apply.
For example, "\." can be used to place a dot character in a label.
- \DDD where each D is a digit is the octet corresponding to the decimal
number described by DDD.
The resulting octet is assumed to be text and is not checked for
special meaning.
For quoted string, inside a " delimited string any character can occur,
except for a " itself, which must be quoted using \ (back slash).
[character-string]: https://datatracker.ietf.org/doc/html/rfc1035#section-5.1
|
|
While at it, fix parsing multiline SOA record where closing parentheses
end on next lines.
Fixes #6
|
|
Using []byte is more common, for example from content of file, rather
than string. It also minimize creating new string.
|
|
In RFC 1035 there is no clear definition whether origin end with dot or
not. The only explanation is on page 33.
... Domain names that end in a dot are called
absolute, and are taken as complete. Domain names which do not end in a
dot are called relative; the actual domain name is the concatenation of
the relative part with an origin specified in a $ORIGIN, $INCLUDE, or as
an argument to the master file loading routine.
Also, most of examples that we found use dot for terminating origin.
|
|
The Reset method reset the zoneParser by parsing from parameter string
data.
Using name Init a little bit confusing.
|
|
Instead of accepting the file, accept Zone where the ZoneParse will
write the result of parsing.
|
|
Using ":=" simplify the code but we lose the type. For example,
v := F()
The only way we know what the type of v is by inspecting the function
F.
Another disadvantages of using ":=" may cause extra variables
allocation where two or more variables with same type is declared
inside body of function where it could be only one.
While at it, we split the struct for test case into separate type.
|
|
|
|
Reason: A Zone is not always represented by file, it just that in this
package, it is.
This changes rename the type ZoneFile into Zone.
|
|
Using the fieldalignment, we got the following output,
answer.go:15:13: struct with 56 pointer bytes could be 24 = 32 bytes
caches.go:27:13: struct with 24 pointer bytes could be 16 = 8
dot_client.go:20:16: struct with 16 pointer bytes could be 8 = 8
hosts_file.go:24:16: struct with 64 pointer bytes could be 48 = 16
message.go:53:14: struct of size 176 could be 168 = 8
rdata_mx.go:20:14: struct with 16 pointer bytes could be 8 = 8
rdata_opt.go:18:15: struct with 16 pointer bytes could be 8 = 8
rdata_srv.go:16:15: struct with 64 pointer bytes could be 56 = 8
rdata_wks.go:30:15: struct with 40 pointer bytes could be 32 = 8
request.go:20:14: struct with 32 pointer bytes could be 24 = 8
resource_record.go:24:21: struct with 56 pointer bytes could be 40 = 16
server.go:76:13: struct with 120 pointer bytes could be 112 = 8
server_options.go:20:20: struct of size 240 could be 224 = 16
tcp_client.go:21:16: struct with 40 pointer bytes could be 24 = 16
udp_client.go:24:16: struct with 24 pointer bytes could be 16 = 8
udp_client_pool.go:25:20: struct with 24 pointer bytes could be 16 = 8
zone_file.go:22:15: struct with 128 pointer bytes could be 120 = 8
zone_parser.go:53:17: struct with 88 pointer bytes could be 72 = 16
Turns out the struct that we frequently used, answer and resource_record,
is not optimized.
This changes reorder all structs field to save space in memory.
|
|
Previously, the record class is represented by uint16 using prefix
QueryClassXxx.
This changes make the record class to be an independent type, to make
code more strict (prevent passing invalid value), and readable.
|
|
Previously, we use uint16 to represent type for ResourceRecord Type or
Question type.
To make the code more strict, where parameter or return value, must be
expected as record type, we add new type to represent the RR type:
RecordType.
This changes also rename any variable name of QType or qtype to RType
or rtype because QType is misleading. The type defined the
ResourceRecord to be queried not only question.
|
|
Using pointer to slice on method or function is not a Go idiom.
It is created when I still new to Go.
|
|
This is for consistency for type and variable names.
|
